您正在查看 Kubernetes 版本的文档： v1.19
Kubernetes v1.19 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击 最新版本。
Kubernetes 版本及版本偏差支持策略
本文描述 Kubernetes 各组件之间版本偏差支持策略。 特定的集群部署工具可能会有额外的限制。
版本支持策略
Kubernetes 版本号格式为 x.y.z，其中 x 为大版本号，y 为小版本号，z 为补丁版本号。 版本号格式遵循 Semantic Versioning 规则。 更多信息，请参阅 Kubernetes 发布版本。
Kubernetes 项目会维护最近的三个小版本分支（1.23, 1.22, 1.21）。 Kubernetes 1.19 及更高的版本将获得大约1年的补丁支持。 Kubernetes 1.18 及更早的版本获得大约9个月的补丁支持。
一些 bug 修复，包括安全修复，取决于其严重性和可行性，有可能会反向合并到这三个发布分支。 补丁版本会定期或根据需要从这些分支中发布。 最终是否发布是由发布管理者来决定的。 如需了解更多信息，请查看 Kubernetes 补丁发布。
版本偏差策略
kube-apiserver
在 高可用（HA）集群 中，
多个 kube-apiserver 实例小版本号最多差1。
例如：
- 最新的
kube-apiserver版本号如果是 1.23 - 则受支持的
kube-apiserver版本号包括 1.23 和 1.22
kubelet
kubelet 版本号不能高于 kube-apiserver，最多可以比 kube-apiserver 低两个小版本。
例如：
kube-apiserver版本号如果是 1.23- 受支持的的
kubelet版本将包括 1.23、1.22 和 1.21
说明： 如果 HA 集群中多个kube-apiserver实例版本号不一致，相应的kubelet版本号可选范围也要减小。
例如：
- 如果
kube-apiserver实例同时存在 1.23 和 1.22 kubelet的受支持版本将是 1.22 和 1.21 （1.23 不再支持，因为它比 1.22 版本的kube-apiserver更新）
kube-controller-manager、 kube-scheduler 和 cloud-controller-manager
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本不能高于 kube-apiserver 版本号。
最好它们的版本号与 kube-apiserver 保持一致，但允许比 kube-apiserver 低一个小版本（为了支持在线升级）。
例如：
- 如果
kube-apiserver版本号为 1.23 kube-controller-manager、kube-scheduler和cloud-controller-manager版本支持 1.23 和 1.22
说明： 如果在 HA 集群中，多个kube-apiserver实例版本号不一致，他们也可以跟任意一个kube-apiserver实例通信（例如，通过 load balancer）， 但kube-controller-manager、kube-scheduler和cloud-controller-manager版本可用范围会相应的减小。
例如：
kube-apiserver实例同时存在 1.23 和 1.22 版本kube-controller-manager、kube-scheduler和cloud-controller-manager可以通过 load balancer 与所有的kube-apiserver通信kube-controller-manager、kube-scheduler和cloud-controller-manager可选版本为 1.22 （1.23 不再支持，因为它比 1.22 版本的kube-apiserver更新）
kubectl
kubectl 可以比 kube-apiserver 高一个小版本，也可以低一个小版本。
例如：
- 如果
kube-apiserver当前是 1.23 版本 kubectl则支持 1.24、1.23 和 1.22
说明： 如果 HA 集群中的多个kube-apiserver实例版本号不一致，相应的kubectl可用版本范围也会减小。
例如：
kube-apiserver多个实例同时存在 1.23 和 1.22kubectl可选的版本为 1.23 和 1.22（其他版本不再支持，因为它会比其中某个kube-apiserver实例高或低一个小版本）
支持的组件升级次序
组件之间支持的版本偏差会影响组件升级的顺序。 本节描述组件从版本 1.22 到 1.23 的升级次序。
kube-apiserver
前提条件：
- 单实例集群中，
kube-apiserver实例版本号须是 1.22 - 高可用（HA）集群中，所有的
kube-apiserver实例版本号必须是 1.22 或 1.23（确保满足最新和最旧的实例小版本号相差不大于1） kube-controller-manager、kube-scheduler和cloud-controller-manager版本号必须为 1.22（确保不高于 API server 的版本，且版本号相差不大于1）kubelet实例版本号必须是 1.22 或 1.21（确保版本号不高于 API server，且版本号相差不大于2）- 注册的 admission 插件必须能够处理新的
kube-apiserver实例发送过来的数据：ValidatingWebhookConfiguration和MutatingWebhookConfiguration对象必须升级到可以处理 1.23 版本新加的 REST 资源（或使用 1.15 版本提供的matchPolicy: Equivalent选项）- 插件可以处理任何 1.23 版本新的 REST 资源数据和新加的字段
升级 kube-apiserver 到 1.23
kube-controller-manager、kube-scheduler 和 cloud-controller-manager
前提条件：
kube-apiserver实例必须为 1.23 （HA 集群中，所有的kube-apiserver实例必须在组件升级前完成升级）
升级 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 到 1.23
kubelet
前提条件：
kube-apiserver实例必须为 1.23 版本
kubelet 可以升级到 1.23（或者停留在 1.22 或 1.21）
警告：集群中
kubelet版本号不建议比kube-apiserver低两个版本号：
- 它们必须升级到与
kube-apiserver相差不超过 1 个小版本，才可以升级其他控制面组件- 有可能使用低于 3 个在维护的小版本
kube-proxy
kube-proxy必须与节点上的kubelet的小版本相同kube-proxy一定不能比kube-apiserver小版本更新kube-proxy最多只能比kube-apiserver早两个小版本
例如：
如果 kube-proxy 的版本是 1.21：
kubelet版本必须相同，也是 1.21kube-apiserver版本必须在 1.21 到 1.23 之间（闭区间）