fix outdated content
This commit is contained in:
yuanhao
parent
7a7b6789b8
commit
77071553d9
|
|
@ -30,27 +30,24 @@ Kubernetes 版本号格式为 **x.y.z**，其中 **x** 为大版本号，**y**
|
|||
更多信息，请参阅 [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.
|
||||
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 项目会维护最近的三个小版本分支。
|
||||
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, or as needed.
|
||||
This decision is owned by the [patch release manager](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing).
|
||||
The patch release manager is a member of the [release team for each release](https://github.com/kubernetes/sig-release/tree/master/release-team).
|
||||
-->
|
||||
一些 bug 修复，包括安全修复，根据其安全性和可用性，有可能会回合到这些分支。
|
||||
补丁版本会定期或根据需要从这些分支中发布。 最终是否发布是由
|
||||
[补丁发布团队](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-manager.md#release-timing)
|
||||
来决定的。补丁发布团队同时也是
|
||||
[发布管理者](https://github.com/kubernetes/sig-release/blob/master/release-managers.md)。
|
||||
如需了解更多信息，请查看 [Kubernetes 补丁发布](https://github.com/kubernetes/sig-release/blob/master/releases/patch-releases.md)。
|
||||
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.
|
||||
|
||||
<!--
|
||||
Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.
|
||||
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.
|
||||
-->
|
||||
小版本大约每3个月发布一个，所以每个小版本分支会维护9个月。
|
||||
一些 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
|
||||
|
|
@ -71,11 +68,11 @@ Example:
|
|||
例如：
|
||||
|
||||
<!--
|
||||
* newest `kube-apiserver` is at **1.13**
|
||||
* other `kube-apiserver` instances are supported at **1.13** and **1.12**
|
||||
* newest `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* other `kube-apiserver` instances are supported at **{{< skew latestVersion >}}** and **{{< skew prevMinorVersion >}}**
|
||||
-->
|
||||
* 最新的 `kube-apiserver` 版本号如果是 **1.13**
|
||||
* 其他 `kube-apiserver` 版本号只能是 **1.13** 或 **1.12**
|
||||
* 最新的 `kube-apiserver` 版本号如果是 **{{< skew latestVersion >}}**
|
||||
* 则受支持的 `kube-apiserver` 版本号包括 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
|
||||
|
||||
### kubelet
|
||||
|
||||
|
|
@ -87,13 +84,13 @@ Example:
|
|||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **1.13**
|
||||
* `kubelet` is supported at **1.13**, **1.12**, and **1.11**
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kubelet` is supported at **{{< skew latestVersion >}}**, **{{< skew prevMinorVersion >}}**, and **{{< skew oldestMinorVersion >}}**
|
||||
-->
|
||||
例如：
|
||||
|
||||
* `kube-apiserver` 版本号如果是 **1.13**
|
||||
* `kubelet` 只能是 **1.13** 、 **1.12** 和 **1.11**
|
||||
* `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.
|
||||
|
|
@ -105,13 +102,14 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this
|
|||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **1.13** and **1.12**
|
||||
* `kubelet` is supported at **1.12**, and **1.11** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
|
||||
* `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` 的多个实例同时存在 **1.13** 和 **1.12**
|
||||
* `kubelet` 只能是 **1.12** 或 **1.11**（**1.13** 不再支持，因为它比**1.12**版本的 `kube-apiserver` 更新）
|
||||
* 如果 `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
|
||||
|
|
@ -127,13 +125,13 @@ Example:
|
|||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **1.13**
|
||||
* `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` are supported at **1.13** and **1.12**
|
||||
* `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` 版本号为 **1.13**
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本支持 **1.13** 和 **1.12**
|
||||
* 如果 `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.
|
||||
|
|
@ -146,15 +144,16 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, and
|
|||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **1.13** and **1.12**
|
||||
* `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 **1.12** (**1.13** is not supported because that would be newer than the `kube-apiserver` instance at version **1.12**)
|
||||
* `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` 实例同时存在 **1.13** 和 **1.12** 版本
|
||||
* `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` 可选版本为 **1.12**（**1.13** 不再支持，因为它比 **1.12** 版本的 `kube-apiserver` 更新）
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 可选版本为 **{{< skew prevMinorVersion >}}**
|
||||
（**{{< skew latestVersion >}}** 不再支持，因为它比 **{{< skew prevMinorVersion >}}** 版本的 `kube-apiserver` 更新）
|
||||
|
||||
### kubectl
|
||||
|
||||
|
|
@ -166,13 +165,13 @@ Example:
|
|||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` is at **1.13**
|
||||
* `kubectl` is supported at **1.14**, **1.13**, and **1.12**
|
||||
* `kube-apiserver` is at **{{< skew latestVersion >}}**
|
||||
* `kubectl` is supported at **{{< skew nextMinorVersion >}}**, **{{< skew latestVersion >}}**, and **{{< skew prevMinorVersion >}}**
|
||||
-->
|
||||
例如：
|
||||
|
||||
* 如果 `kube-apiserver` 当前是 **1.13** 版本
|
||||
* `kubectl` 则支持 **1.14** 、**1.13** 和 **1.12**
|
||||
* 如果 `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.
|
||||
|
|
@ -184,13 +183,13 @@ If version skew exists between `kube-apiserver` instances in an HA cluster, this
|
|||
<!--
|
||||
Example:
|
||||
|
||||
* `kube-apiserver` instances are at **1.13** and **1.12**
|
||||
* `kubectl` is supported at **1.13** and **1.12** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components)
|
||||
* `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` 多个实例同时存在 **1.13** 和 **1.12**
|
||||
* `kubectl` 可选的版本为 **1.13** 和 **1.12**（其他版本不再支持，因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本）
|
||||
* `kube-apiserver` 多个实例同时存在 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**
|
||||
* `kubectl` 可选的版本为 **{{< skew latestVersion >}}** 和 **{{< skew prevMinorVersion >}}**（其他版本不再支持，因为它会比其中某个 `kube-apiserver` 实例高或低一个小版本）
|
||||
|
||||
<!--
|
||||
## Supported component upgrade order
|
||||
|
|
@ -199,10 +198,10 @@ Example:
|
|||
|
||||
<!--
|
||||
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 **1.n** to version **1.(n+1)**.
|
||||
This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew prevMinorVersion >}}** to version **{{< skew latestVersion >}}**.
|
||||
-->
|
||||
组件之间支持的版本偏差会影响组件升级的顺序。
|
||||
本节描述组件从版本 **1.n** 到 **1.(n+1)** 的升级次序。
|
||||
本节描述组件从版本 **{{< skew prevMinorVersion >}}** 到 **{{< skew latestVersion >}}** 的升级次序。
|
||||
|
||||
### kube-apiserver
|
||||
|
||||
|
|
@ -212,28 +211,28 @@ Pre-requisites:
|
|||
前提条件：
|
||||
|
||||
<!--
|
||||
* In a single-instance cluster, the existing `kube-apiserver` instance is **1.n**
|
||||
* In an HA cluster, all `kube-apiserver` instances are at **1.n** or **1.(n+1)** (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 **1.n** (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 **1.n** or **1.(n-1)** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version)
|
||||
* 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 **1.(n+1)** (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 **1.(n+1)**
|
||||
* `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` 实例版本号须是 **1.n**
|
||||
* HA 集群时，所有的 `kube-apiserver` 实例版本号必须是 **1.n** 或 **1.(n+1)**（确保满足最新和最旧的实例小版本号相差不大于1）
|
||||
* `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本号必须为 **1.n**（确保不高于 API server 的版本，且版本号相差不大于1）
|
||||
* `kubelet` 实例版本号必须是 **1.n** 或 **1.(n-1)**（确保版本号不高于 API server，且版本号相差不大于2）
|
||||
* 单实例集群中，`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` 对象必须升级到可以处理
|
||||
**1.(n+1)** 版本新加的 REST 资源（或使用 1.15 版本提供的
|
||||
**{{< skew latestVersion >}}** 版本新加的 REST 资源（或使用 1.15 版本提供的
|
||||
[`matchPolicy: Equivalent` 选项](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)）
|
||||
* 插件可以处理任何 **1.(n+1)** 版本新的 REST 资源数据和新加的字段
|
||||
* 插件可以处理任何 **{{< skew latestVersion >}}** 版本新的 REST 资源数据和新加的字段
|
||||
|
||||
<!--
|
||||
Upgrade `kube-apiserver` to **1.(n+1)**
|
||||
Upgrade `kube-apiserver` to **{{< skew latestVersion >}}**
|
||||
-->
|
||||
升级 `kube-apiserver` 到 **1.(n+1)**
|
||||
升级 `kube-apiserver` 到 **{{< skew latestVersion >}}**
|
||||
|
||||
{{< note >}}
|
||||
<!--
|
||||
|
|
@ -241,7 +240,7 @@ Project policies for [API deprecation](/docs/reference/using-api/deprecation-pol
|
|||
[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 弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 和
|
||||
[API 变更指南](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md)，
|
||||
`kube-apiserver` 不能跨小版本号升级，即使是单实例集群也不可以。
|
||||
|
||||
|
|
@ -255,31 +254,31 @@ require `kube-apiserver` to not skip minor versions when upgrading, even in sing
|
|||
<!--
|
||||
Pre-requisites:
|
||||
|
||||
* The `kube-apiserver` instances these components communicate with are at **1.(n+1)** (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)
|
||||
* 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` 实例必须为 **1.(n+1)** （HA 集群中，所有的`kube-apiserver` 实例必须在组件升级前完成升级）
|
||||
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** （HA 集群中，所有的`kube-apiserver` 实例必须在组件升级前完成升级）
|
||||
|
||||
<!--
|
||||
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **1.(n+1)**
|
||||
Upgrade `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` to **{{< skew latestVersion >}}**
|
||||
-->
|
||||
升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 到 **1.(n+1)**
|
||||
升级 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 到 **{{< skew latestVersion >}}**
|
||||
|
||||
### kubelet
|
||||
|
||||
<!--
|
||||
Pre-requisites:
|
||||
|
||||
* The `kube-apiserver` instances the `kubelet` communicates with are at **1.(n+1)**
|
||||
* The `kube-apiserver` instances the `kubelet` communicates with are at **{{< skew latestVersion >}}**
|
||||
|
||||
Optionally upgrade `kubelet` instances to **1.(n+1)** (or they can be left at **1.n** or **1.(n-1)**)
|
||||
Optionally upgrade `kubelet` instances to **{{< skew latestVersion >}}** (or they can be left at **{{< skew prevMinorVersion >}}** or **{{< skew oldestMinorVersion >}}**)
|
||||
-->
|
||||
前提条件：
|
||||
|
||||
* `kube-apiserver` 实例必须为 **1.(n+1)** 版本
|
||||
* `kube-apiserver` 实例必须为 **{{< skew latestVersion >}}** 版本
|
||||
|
||||
`kubelet` 可以升级到 **1.(n+1)**（或者停留在 **1.n** 或 **1.(n-1)**）
|
||||
`kubelet` 可以升级到 **{{< skew latestVersion >}}**（或者停留在 **{{< skew prevMinorVersion >}}** 或 **{{< skew oldestMinorVersion >}}**）
|
||||
|
||||
<!--
|
||||
Running a cluster with `kubelet` instances that are persistently two minor versions behind `kube-apiserver` is not recommended:
|
||||
|
|
@ -293,3 +292,30 @@ Running a cluster with `kubelet` instances that are persistently two minor versi
|
|||
* 它们必须升级到与 `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 >}}** 之间（闭区间）
|
||||
Loading…
Reference in New Issue