本文档描述了 Kubernetes 各个组件之间所支持的最大版本偏差。 特定的集群部署工具可能会对版本偏差添加额外的限制。
Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本， y 是次要版本，z 是补丁版本，遵循语义版本控制术语。 更多信息请参见 Kubernetes 版本发布控制。
Kubernetes 项目维护最近的三个次要版本（1.35、1.34、1.33）的发布分支。 Kubernetes 1.19 和更新的版本获得大约 1 年的补丁支持。 Kubernetes 1.18 及更早的版本获得了大约 9 个月的补丁支持。
适当的修复，包括安全问题修复，可能会被后沿三个发布分支，具体取决于问题的严重性和可行性。 补丁版本按常规节奏从这些分支中删除，并在需要时增加额外的紧急版本。
发布管理员小组拥有这件事的决定权。
有关更多信息，请参阅 Kubernetes 补丁发布页面。
在高可用性（HA）集群中，
最新版和最老版的 kube-apiserver 实例版本偏差最多为一个次要版本。
例如：
kube-apiserver 实例处于 1.35 版本kube-apiserver 实例支持 1.35 和 1.34 版本kubelet 版本不能比 kube-apiserver 版本新。kubelet 可以比 kube-apiserver 低三个次要版本（如果 kubelet < 1.25，则只能比 kube-apiserver 低两个次要版本）。例如：
kube-apiserver 处于 1.35 版本kubelet 支持 1.35、1.34、1.33 和 1.32 版本如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，这会缩小允许的 kubelet 版本范围。
例如：
kube-apiserver 实例处于 1.35 和 1.34 版本kubelet 支持 1.34、1.33 和 1.32 版本，
（不支持 1.35 版本，因为这将比
kube-apiserver 1.34 版本的实例新）kube-proxy 不能比 kube-apiserver 新。kube-proxy 最多可以比 kube-apiserver 旧三个小版本（kube-proxy < 1.25 最多只能比 kube-apiserver 旧两个小版本）。kube-proxy 可能比它旁边运行的 kubelet 实例旧或新最多三个次要版本（kube-proxy < 1.25 最多只能是比它并行运行的 kubelet 实例旧或新的两个次要版本）。例如：
kube-apiserver 的版本是 1.35kube-proxy 支持的版本是 1.35、
1.34 、1.33 和
1.32如果在 HA 集群中的 kube-apiserver 实例之间存在版本偏差，
所允许的 kube-proxy 版本范围会被缩小。
例如：
kube-apiserver 实例的版本是 1.35 和 1.34kube-proxy 版本为 1.34、
1.33 和 1.32。（1.35 将不被支持，
因为该版本将比 1.34 的 kube-apiserver 实例更新）kube-controller-manager、kube-scheduler 和 cloud-controller-manager
不能比与它们通信的 kube-apiserver 实例新。
它们应该与 kube-apiserver 次要版本相匹配，但可能最多旧一个次要版本（允许实时升级）。
例如：
kube-apiserver 处于 1.35 版本kube-controller-manager、kube-scheduler 和 cloud-controller-manager
支持 1.35 和 1.34 版本如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，
并且这些组件可以与集群中的任何 kube-apiserver
实例通信（例如，通过负载均衡器），这会缩小这些组件所允许的版本范围。
例如：
kube-apiserver 实例处于
1.35 和 1.34 版本kube-controller-manager、kube-scheduler 和 cloud-controller-manager
与可以路由到任何 kube-apiserver 实例的负载均衡器通信kube-controller-manager、kube-scheduler 和 cloud-controller-manager
支持 1.34 版本（不支持 1.35
版本，因为它比 1.34 版本的 kube-apiserver 实例新）kubectl 在 kube-apiserver 的一个次要版本（较旧或较新）中支持。
例如：
kube-apiserver 处于 1.35 版本kubectl 支持 1.36、1.35
和 1.34 版本如果 HA 集群中的 kube-apiserver 实例之间存在版本偏差，这会缩小支持的 kubectl 版本范围。
例如：
kube-apiserver 实例处于
1.35 和 1.34 版本kubectl 支持 1.35 和 1.34
版本（其他版本将与 kube-apiserver 组件之一相差不止一个的次要版本）组件之间支持的版本偏差会影响必须升级组件的顺序。 本节介绍了将现有集群从 1.34 版本转换到 1.35 版本时必须升级组件的顺序。
作为一种可选方案，在准备升级时，Kubernetes 项目建议你执行以下操作， 有利于升级时包含尽可能多的回归和错误修复：
例如，如果你正在运行版本 1.34， 请确保你使用的是最新的补丁版本。 然后，升级到 1.35 的最新补丁版本。
先决条件：
kube-apiserver 实例处于 1.34 版本kube-apiserver 实例都处于
1.34 或 1.35 版本
（这确保了最老和最新的 kube-apiserver 实例之间的 1 个次要版本的最大偏差）kube-controller-manager、kube-scheduler 和 cloud-controller-manager
实例的版本为 1.34
（这确保它们是不比现有 API 服务器版本还要新，并且在新 API 服务器版本的 1 个次要版本内）kubelet 实例都是
1.34 或 1.33
版本（这确保它们不比现有 API 服务器版本新，并且在新 API 服务器版本的 2 个次要版本内）kube-apiserver 实例将发送给他们的数据：ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration
对象已更新以包含 1.35 中添加的任何新版本的 REST 资源
（或使用 v1.15+ 中可用的 matchPolicy: Equivalent 选项）将 kube-apiserver 升级到 1.35 版本
先决条件：
kube-apiserver 实例处于 1.35 版本
（在 HA 集群中，这些控制平面组件可以与集群中的任何 kube-apiserver 实例通信，
所有 kube-apiserver 实例必须在升级这些组件之前升级）将 kube-controller-manager、kube-scheduler 和 cloud-controller-manager
升级到 1.35 版本。
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 的升级顺序没有要求。
你可以按任意顺序升级这些组件，甚至可以同时升级这些组件。
先决条件：
kubelet 通信的 kube-apiserver 实例处于 1.35 版本可选择将 kubelet 实例升级到 版本
（或者它们可以留在 1.34 或 1.33 或 1.32 版本）
在执行次要版本 kubelet 升级之前，排空该节点的 Pod。
kubelet 不支持原地次要版本升级。
在一个集群中运行持续比 kube-apiserver 落后两个次版本的 kubelet 实例意味着在升级控制平面之前必须先升级它们。
前提条件：
在一个集群中运行持续比 kube-apiserver 落后三个次版本的 kube-proxy 实例意味着在升级控制平面之前必须先升级它们。