[zh] Setup files to sync for 1.22(part-5)

This commit is contained in:
Mengjiao Liu 2021-08-27 18:16:04 +08:00
parent f76c2a7b63
commit 12181a4d7c
5 changed files with 73 additions and 2101 deletions

View File

@ -1,9 +1,9 @@
---
no_issue: true
title: 入门
main_menu: true
weight: 20
content_type: concept
no_list: true
card:
name: setup
weight: 20
@ -19,11 +19,11 @@ reviewers:
- brendandburns
- erictune
- mikedanese
no_issue: true
title: Getting started
main_menu: true
weight: 20
content_type: concept
no_list: true
card:
name: setup
weight: 20
@ -48,10 +48,17 @@ control, available resources, and expertise required to operate and manage a clu
安装 Kubernetes 时,请根据以下条件选择安装类型:易于维护、安全性、可控制性、可用资源以及操作和管理 Kubernetes 集群所需的专业知识。
<!--
You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. There are also custom solutions across a wide range of cloud providers, or bare metal environments.
-->
可以在本地机器、云、本地数据中心上部署 Kubernetes 集群,或选择一个托管的 Kubernetes 集群。还可以跨各种云提供商或裸机环境创建自定义解决方案。
You can [download Kubernetes](/releases/download/) to deploy a Kubernetes cluster
on a local machine, into the cloud, or for your own datacenter.
If you don't want to manage a Kubernetes cluster yourself, you could pick a managed service, including
[certified platforms](/docs/setup/production-environment/turnkey-solutions/).
There are also other standardized and custom solutions across a wide range of cloud and
bare metal environments.
-->。
可以[下载 Kubernetes](/releases/download/),在本地机器、云或你自己的数据中心上部署 Kubernetes 集群。
如果你不想自己管理 Kubernetes 集群,则可以选择托管服务,包括[经过认证的平台](/zh/docs/setup/production-environment/turnkey-solutions/)。
在各种云和裸机环境中,还有其他标准化和定制的解决方案。
<!-- body -->
<!--
@ -60,9 +67,13 @@ You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacente
## 学习环境
<!--
If you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
If you're learning Kubernetes, use the tools supported by the Kubernetes community,
or tools in the ecosystem to set up a Kubernetes cluster on a local machine.
See [Install tools](/docs/tasks/tools/).
-->
如果正打算学习 Kubernetes请使用 Kubernetes 社区支持或生态系统中的工具在本地计算机上设置 Kubernetes 集群。
如果正打算学习 Kubernetes请使用 Kubernetes 社区支持
或生态系统中的工具在本地计算机上设置 Kubernetes 集群。
请参阅[安装工具](/zh/docs/tasks/tools/)。
<!--
## Production environment
@ -70,12 +81,40 @@ If you're learning Kubernetes, use the tools supported by the Kubernetes communi
## 生产环境
<!--
When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider.
When evaluating a solution for a
[production environment](/docs/setup/production-environment/), consider which aspects of
operating a Kubernetes cluster (or _abstractions_) you want to manage yourself and which you
prefer to hand off to a provider.
For a cluster you're managing yourself, the officially supported tool
for deploying Kubernetes is [kubeadm](/docs/setup/production-environment/tools/kubeadm/).
-->
在评估生产环境的解决方案时,请考虑要管理自己 Kubernetes 集群_抽象层面_的哪些方面或将其转移给提供商。
在评估[生产环境](/zh/docs/setup/production-environment/)的解决方案时,
请考虑要自己管理 Kubernetes 集群(或相关抽象)的哪些方面,将哪些托付给提供商。
对于你自己管理的集群,官方支持的用于部署 Kubernetes 的工具是
[kubeadm](/zh/docs/setup/production-environment/tools/kubeadm/)。
<!--
[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers.
## {{% heading "whatsnext" %}}
- [Download Kubernetes](/releases/download/)
- Download and [install tools](/docs/tasks/tools/) including `kubectl`
- Select a [container runtime](/docs/setup/production-environment/container-runtimes/) for your new cluster
- Learn about [best practices](/docs/setup/best-practices/) for cluster setup
Kubernetes is designed for its {{< glossary_tooltip term_id="control-plane" text="control plane" >}} to
run on Linux. Within your cluster you can run applications on Linux or other operating systems, including
Windows.
- Learn to [set up clusters with Windows nodes](/docs/setup/production-environment/windows/)
-->
[Kubernetes 合作伙伴](https://kubernetes.io/zh/partners/#kcsp) 包括一个
[已认证的 Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 提供商列表。
## {{% heading "whatsnext" %}}
- [下载 Kubernetes](/releases/download/)
- 下载并[安装工具](/zh/docs/tasks/tools/),包括 kubectl 在内
- 为新集群选择[容器运行时](/zh/docs/setup/production-environment/container-runtimes/)
- 了解集群设置的[最佳实践](/zh/docs/setup/best-practices/)
Kubernetes 的设计是让其{{< glossary_tooltip term_id="control-plane" text="控制平面" >}}在 Linux 上运行的。
在集群中,你可以在 Linux 或其他操作系统(包括 Windows上运行应用程序。
- 学习[配置包含 Windows 节点的集群](/zh/docs/setup/production-environment/windows/)

View File

@ -25,12 +25,12 @@ Kubernetes {{< param "version" >}} 支持的最大节点数为 5000。
更具体地说Kubernetes旨在适应满足以下*所有*标准的配置:
<!--
* No more than 100 pods per node
* No more than 110 pods per node
* No more than 5000 nodes
* No more than 150000 total pods
* No more than 300000 total containers
-->
* 每个节点的 Pod 数量不超过 100
* 每个节点的 Pod 数量不超过 110
* 节点数不超过 5000
* Pod 总数不超过 150000
* 容器总数不超过 300000
@ -46,7 +46,7 @@ on how your cluster is deployed.
To avoid running into cloud provider quota issues, when creating a cluster with many nodes,
consider:
* Request a quota increase for cloud resources such as:
* Requesting a quota increase for cloud resources such as:
* Computer instances
* CPUs
* Storage volumes
@ -55,7 +55,7 @@ consider:
* Number of load balancers
* Network subnets
* Log streams
* Gate the cluster scaling actions to brings up new nodes in batches, with a pause
* Gating the cluster scaling actions to brings up new nodes in batches, with a pause
between batches, because some cloud providers rate limit the creation of new instances.
-->
## 云供应商资源配额 {#quota-issues}
@ -132,6 +132,15 @@ When creating a cluster, you can (using custom tooling):
* 启动并配置额外的 etcd 实例
* 配置 {{< glossary_tooltip term_id="kube-apiserver" text="API 服务器" >}},将它用于存储事件
<!--
See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and
[Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
for details on configuring and managing etcd for a large cluster.
-->
有关为大型集群配置和管理 etcd 的详细信息,请参阅
[为 Kubernetes 运行 etcd 集群](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/)
和使用 [kubeadm 创建一个高可用 etcd 集群](/zh/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)。
<!--
### Addon Resources
-->
@ -226,4 +235,12 @@ nodes for the level of resource demand in your cluster.
以及如何使用它来扩展集群组件(包括对集群至关重要的插件)的信息。
[集群自动扩缩器](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)
与许多云供应商集成在一起,帮助你在你的集群中,按照资源需求级别运行正确数量的节点。
与许多云供应商集成在一起,帮助你在你的集群中,按照资源需求级别运行正确数量的节点。
<!--
The [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
helps you in resizing the addons automatically as your cluster's scale changes.
-->
[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
可帮助你在集群规模变化时自动调整插件的大小。

View File

@ -1,4 +0,0 @@
---
title: "Kubernetes 发行说明和版本偏差"
weight: 10
---

File diff suppressed because it is too large Load Diff

View File

@ -1,365 +0,0 @@
---
title: Kubernetes 版本及版本偏差支持策略
content_type: concept
weight: 30
---
<!-- overview -->
<!--
This document describes the maximum version skew supported between various Kubernetes components.
Specific cluster deployment tools may place additional restrictions on version skew.
-->
本文描述 Kubernetes 各组件之间版本偏差支持策略。
特定的集群部署工具可能会有额外的限制。
<!-- body -->
<!--
## Supported versions
-->
## 版本支持策略
<!--
Kubernetes versions are expressed as **x.y.z**,
where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](http://semver.org/) terminology.
For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning).
-->
Kubernetes 版本号格式为 **x.y.z**,其中 **x** 为大版本号,**y** 为小版本号,**z** 为补丁版本号。
版本号格式遵循 [Semantic Versioning](https://semver.org/) 规则。
更多信息,请参阅
[Kubernetes 发布版本](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)。
<!--
The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.
-->
Kubernetes 项目会维护最近的三个小版本分支({{< skew latestVersion >}},
{{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})。
Kubernetes 1.19 及更高的版本将获得大约1年的补丁支持。
Kubernetes 1.18 及更早的版本获得大约9个月的补丁支持。
<!--
Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility.
Patch releases are cut from those branches at a [regular cadence](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence), plus additional urgent releases, when required.
The [Release Managers](https://git.k8s.io/sig-release/release-managers.md) group owns this decision.
For more information, see the Kubernetes [patch releases](https://git.k8s.io/sig-release/releases/patch-releases.md) page.
-->
一些 bug 修复,包括安全修复,取决于其严重性和可行性,有可能会反向合并到这三个发布分支。
补丁版本会[定期](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence)
或根据需要从这些分支中发布。
最终是否发布是由
[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)
来决定的。
如需了解更多信息,请查看 Kubernetes
[补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
<!--
## Supported version skew
-->
## 版本偏差策略
### kube-apiserver
<!--
In [highly-available (HA) clusters](/docs/setup/production-environment/tools/kubeadm/high-availability/), the newest and oldest `kube-apiserver` instances must be within one minor version.
-->
在 [高可用HA集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) 中,
多个 `kube-apiserver` 实例小版本号最多差1。
<!--
Example:
-->
例如:
<!--
* newest `kube-apiserver` is at **{{< skew latestVersion >}}**
* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
-->
* 最新的 `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
* 其他受支持的 `kube-apiserver` 版本号包括 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**
### kubelet
<!--
`kubelet` must not be newer than `kube-apiserver`, and may be up to two minor versions older.
-->
`kubelet` 版本号不能高于 `kube-apiserver`,最多可以比 `kube-apiserver` 低两个小版本。
<!--
Example:
* `kube-apiserver` is at **{{< skew latestVersion >}}**
* `kubelet` is supported at **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}**
-->
例如:
* `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
* 受支持的的 `kubelet` 版本将包括 **{{< skew latestVersion >}}**、
**{{< skew prevMinorVersion >}}** 和 **{{< skew oldestMinorVersion >}}**
<!--
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the allowed `kubelet` versions.
-->
{{< note >}}
如果 HA 集群中多个 `kube-apiserver` 实例版本号不一致,相应的 `kubelet` 版本号可选范围也要减小。
{{</ note >}}
<!--
Example:
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
* `kubelet` is supported at **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
-->
例如:
* 如果 `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**
* `kubelet` 的受支持版本将是 **{{< skew prevMinorVersion >}}** 和
**{{< skew oldestMinorVersion >}}**
**{{< skew latestVersion >}}** 不再支持,因为它比
**{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新)
<!--
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
-->
### kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
<!--
`kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` must not be newer than the `kube-apiserver` instances they communicate with. They are expected to match the `kube-apiserver` minor version, but may be up to one minor version older (to allow live upgrades).
-->
`kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本不能高于 `kube-apiserver` 版本号。
最好它们的版本号与 `kube-apiserver` 保持一致,但允许比 `kube-apiserver`
低一个小版本(为了支持在线升级)。
<!--
Example:
* `kube-apiserver` is at **{{< skew latestVersion >}}**
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
-->
例如:
* 如果 `kube-apiserver` 版本号为 **{{< skew latestVersion >}}**
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本支持 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
<!--
If version skew exists between `kube-apiserver` instances in an HA cluster, and these components can communicate with any `kube-apiserver` instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.
-->
{{< note >}}
如果在 HA 集群中,多个 `kube-apiserver` 实例版本号不一致,他们也可以跟
任意一个 `kube-apiserver` 实例通信(例如,通过 load balancer
`kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本可用范围会相应的减小。
{{< /note >}}
<!--
Example:
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` communicate with a load balancer that can route to any `kube-apiserver` instance
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **{{< skew prevMinorVersion >}}** (**{{< skew latestVersion >}}** is not supported because that would be newer than the `kube-apiserver` instance at version **{{< skew prevMinorVersion >}}**)
-->
例如:
* `kube-apiserver` 实例同时存在 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}** 版本
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
可以通过 load balancer 与所有的 `kube-apiserver` 通信
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
可选版本为 **{{< skew prevMinorVersion >}}**
**{{< skew latestVersion >}}** 不再支持,因为它比 **{{< skew prevMinorVersion >}}**
版本的 `kube-apiserver` 更新)
### kubectl
<!--
`kubectl` is supported within one minor version (older or newer) of `kube-apiserver`.
-->
`kubectl` 可以比 `kube-apiserver` 高一个小版本,也可以低一个小版本。
<!--
Example:
* `kube-apiserver` is at **{{< skew latestVersion >}}**
* `kubectl` is supported at **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}**, and **{{< skew prevMinorVersion >}}**
-->
例如:
* 如果 `kube-apiserver` 当前是 **{{< skew latestVersion >}}** 版本
* `kubectl` 则支持 **{{< skew nextMinorVersion >}}**、**{{< skew latestVersion >}}**
**{{< skew prevMinorVersion >}}**
<!--
If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions.
-->
{{< note >}}
如果 HA 集群中的多个 `kube-apiserver` 实例版本号不一致,相应的 `kubectl` 可用版本范围也会减小。
{{< /note >}}
<!--
Example:
* `kube-apiserver` instances are at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
* `kubectl` is supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
-->
例如:
* `kube-apiserver` 多个实例同时存在 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**
* `kubectl` 可选的版本为 **{{< skew latestVersion >}}** 和
**{{< skew prevMinorVersion >}}**(其他版本不再支持,
因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本)
<!--
## Supported component upgrade order
-->
## 支持的组件升级次序
<!--
The supported version skew between components has implications on the order in which components must be upgraded.
This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
-->
组件之间支持的版本偏差会影响组件升级的顺序。
本节描述组件从版本 **{{< skew prevMinorVersion >}}** 到 **{{< skew latestVersion >}}**
的升级次序。
### kube-apiserver
<!--
Pre-requisites:
-->
前提条件:
<!--
* In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew prevMinorVersion >}}**
* In an HA cluster, all `kube-apiserver` instances are at **{{< skew prevMinorVersion >}}** or **{{< skew latestVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance)
* The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **{{< skew prevMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version)
* `kubelet` instances on all nodes are at version **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
* Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them:
* `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **{{< skew latestVersion >}}** (or use the [`matchPolicy: Equivalent` option](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy) available in v1.15+)
* The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in **{{< skew latestVersion >}}**
-->
* 单实例集群中,`kube-apiserver` 实例版本号须是 **{{< skew prevMinorVersion >}}**
* 高可用HA集群中所有的 `kube-apiserver` 实例版本号必须是
**{{< skew prevMinorVersion >}}** 或 **{{< skew latestVersion >}}**
确保满足最新和最旧的实例小版本号相差不大于1
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
版本号必须为 **{{< skew prevMinorVersion >}}**
(确保不高于 API server 的版本且版本号相差不大于1
* `kubelet` 实例版本号必须是 **{{< skew prevMinorVersion >}}** 或
**{{< skew oldestMinorVersion >}}**(确保版本号不高于 API server且版本号相差不大于2
* 注册的 admission 插件必须能够处理新的 `kube-apiserver` 实例发送过来的数据:
* `ValidatingWebhookConfiguration``MutatingWebhookConfiguration` 对象必须升级到可以处理
**{{< skew latestVersion >}}** 版本新加的 REST 资源(或使用 1.15 版本提供的
[`matchPolicy: Equivalent` 选项](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)
* 插件可以处理任何 **{{< skew latestVersion >}}** 版本新的 REST 资源数据和新加的字段
<!--
Upgrade `kube-apiserver` to **{{< skew latestVersion >}}**
-->
升级 `kube-apiserver`**{{< skew latestVersion >}}**
{{< note >}}
<!--
Project policies for [API deprecation](/docs/reference/using-api/deprecation-policy/) and
[API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
require `kube-apiserver` to not skip minor versions when upgrading, even in single-instance clusters.
-->
根据 [API 弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 和
[API 变更指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)
`kube-apiserver` 不能跨小版本号升级,即使是单实例集群也不可以。
{{< /note >}}
<!--
### kube-controller-manager, kube-scheduler, and cloud-controller-manager
-->
### kube-controller-manager、kube-scheduler 和 cloud-controller-manager
<!--
Pre-requisites:
* The `kube-apiserver` instances these components communicate with are at **{{< skew latestVersion >}}** (in HA clusters in which these control plane components can communicate with any `kube-apiserver` instance in the cluster, all `kube-apiserver` instances must be upgraded before upgrading these components)
-->
前提条件:
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}**
HA 集群中,所有的`kube-apiserver` 实例必须在组件升级前完成升级)
<!--
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew latestVersion >}}**
-->
升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager`
**{{< skew latestVersion >}}**
### kubelet
<!--
Pre-requisites:
* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew latestVersion >}}**
Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
-->
前提条件:
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** 版本
`kubelet` 可以升级到 **{{< skew latestVersion >}}**(或者停留在
**{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**
{{< note >}}
<!--
Before performing a minor version `kubelet` upgrade, [drain](/docs/tasks/administer-cluster/safely-drain-node/) pods from that node.
In-place minor version `kubelet` upgrades are not supported.
-->
在对 `kubelet` 执行次版本升级时,先[腾空](/zh/docs/tasks/administer-cluster/safely-drain-node/)
节点上的 Pods。
目前不支持原地升级 `kubelet` 的次版本。
{{</ note >}}
{{< warning >}}
<!--
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
* they must be upgraded within one minor version of `kube-apiserver` before the control plane can be upgraded
* it increases the likelihood of running `kubelet` versions older than the three maintained minor releases
-->
集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号:
* 它们必须升级到与 `kube-apiserver` 相差不超过 1 个小版本,才可以升级其他控制面组件
* 有可能使用低于 3 个在维护的小版本
{{</ warning >}}
<!-- ### kube-proxy -->
### kube-proxy
<!--
* `kube-proxy` must be the same minor version as `kubelet` on the node.
* `kube-proxy` must not be newer than `kube-apiserver`.
* `kube-proxy` must be at most two minor versions older than `kube-apiserver.`
-->
* `kube-proxy` 必须与节点上的 `kubelet` 的小版本相同
* `kube-proxy` 一定不能比 `kube-apiserver` 小版本更新
* `kube-proxy` 最多只能比 `kube-apiserver` 早两个小版本
<!--
Example:
If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**:
* `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**.
* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
-->
例如:
如果 `kube-proxy` 的版本是 **{{< skew oldestMinorVersion >}}**
* `kubelet` 版本必须相同,也是 **{{< skew oldestMinorVersion >}}**
* `kube-apiserver` 版本必须在 **{{< skew oldestMinorVersion >}}** 到
**{{< skew latestVersion >}}** 之间(闭区间)