Kubernetes 版本及版本偏差支持策略

Kubernetes 版本号格式为 x.y.z，其中 x 为大版本号，y 为小版本号，z 为补丁版本号。版本号格式遵循规则。更多信息，请参阅 Kubernetes 发布版本。

Kubernetes 项目会维护最近的三个小版本分支（1.20, 1.19, 1.18）。 Kubernetes 1.19 及更高的版本将获得大约1年的补丁支持。 Kubernetes 1.18 及更早的版本获得大约9个月的补丁支持。

一些 bug 修复，包括安全修复，取决于其严重性和可行性，有可能会反向合并到这三个发布分支。补丁版本会或根据需要从这些分支中发布。最终是否发布是由发布管理者来决定的。如需了解更多信息，请查看 Kubernetes 。

在高可用（HA）集群中，多个实例小版本号最多差1。

例如：

kubelet 版本号不能高于 kube-apiserver，最多可以比 kube-apiserver 低两个小版本。

例如：

例如：

如果 kube-apiserver 实例同时存在 1.20 和 1.19
kubelet 的受支持版本将是 1.19 和 1.18 （1.20 不再支持，因为它比 1.19 版本的 kube-apiserver 更新）

例如：

如果 kube-apiserver 版本号为 1.20
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本支持 1.20 和 1.19

例如：

kube-apiserver 实例同时存在 1.20 和 1.19 版本
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可以通过 load balancer 与所有的 kube-apiserver 通信
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可选版本为 1.19 （1.20 不再支持，因为它比 1.19 版本的 kube-apiserver 更新）

kubectl 可以比 kube-apiserver 高一个小版本，也可以低一个小版本。

例如：

例如：

kube-apiserver 多个实例同时存在 1.20 和 1.19
kubectl 可选的版本为 1.20 和 1.19（其他版本不再支持，因为它会比其中某个 kube-apiserver 实例高或低一个小版本）

组件之间支持的版本偏差会影响组件升级的顺序。本节描述组件从版本 1.19 到 1.20 的升级次序。

前提条件：

单实例集群中，kube-apiserver 实例版本号须是 1.19
kube-controller-manager、kube-scheduler 和版本号必须为 1.19（确保不高于 API server 的版本，且版本号相差不大于1）
kubelet 实例版本号必须是 1.19 或 1.18（确保版本号不高于 API server，且版本号相差不大于2）
注册的 admission 插件必须能够处理新的 kube-apiserver 实例发送过来的数据：
- ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象必须升级到可以处理 1.20 版本新加的 REST 资源（或使用 1.15 版本提供的）
- 插件可以处理任何 1.20 版本新的 REST 资源数据和新加的字段

前提条件：

升级 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 到 1.20

前提条件：

kubelet 可以升级到 1.20（或者停留在 1.19 或 1.18）

例如：