版本偏差策略

本文档描述了 Kubernetes 各个组件之间所支持的最大版本偏差。 特定的集群部署工具可能会对版本偏差添加额外的限制。

支持的版本

Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本， y 是次要版本，z 是补丁版本，遵循语义版本控制术语。 更多信息请参见 Kubernetes 版本发布控制。

Kubernetes 项目维护最近的三个次要版本（1.32、1.31、1.30）的发布分支。 Kubernetes 1.19 和更新的版本获得大约 1 年的补丁支持。 Kubernetes 1.18 及更早的版本获得了大约 9 个月的补丁支持。

适当的修复，包括安全问题修复，可能会被后沿三个发布分支，具体取决于问题的严重性和可行性。 补丁版本按常规节奏从这些分支中删除，并在需要时增加额外的紧急版本。

发布管理员小组拥有这件事的决定权。

有关更多信息，请参阅 Kubernetes 补丁发布页面。

支持的版本偏差

kube-apiserver

在高可用性（HA）集群中， 最新版和最老版的 kube-apiserver 实例版本偏差最多为一个次要版本。

例如：

• 最新的 kube-apiserver 实例处于 1.32 版本
• 其他 kube-apiserver 实例支持 1.32 和 1.31 版本

kubelet

• kubelet 版本不能比 kube-apiserver 版本新。
• kubelet 可以比 kube-apiserver 低三个次要版本（如果 kubelet < 1.25，则只能比 kube-apiserver 低两个次要版本）。

例如：

• kube-apiserver 处于 1.32 版本
• kubelet 支持 1.32、1.31、1.30 和 1.29 版本

例如：

• kube-apiserver 实例处于 1.32 和 1.31 版本
• kubelet 支持 1.31、1.30 和 1.29 版本， （不支持 1.32 版本，因为这将比 kube-apiserver 1.31 版本的实例新）

kube-proxy

• 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.32
• kube-proxy 支持的版本是 1.32、 1.31 、1.30 和 1.29

例如：

• kube-apiserver 实例的版本是 1.32 和 1.31
• kube-proxy 版本为 1.31、 1.30 和 1.29。（1.32 将不被支持， 因为该版本将比 1.31 的 kube-apiserver 实例更新）

kube-controller-manager、kube-scheduler 和 cloud-controller-manager

kube-controller-manager、kube-scheduler 和 cloud-controller-manager 不能比与它们通信的 kube-apiserver 实例新。 它们应该与 kube-apiserver 次要版本相匹配，但可能最多旧一个次要版本（允许实时升级）。

例如：

• kube-apiserver 处于 1.32 版本
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.32 和 1.31 版本

例如：

• kube-apiserver 实例处于 1.32 和 1.31 版本
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 与可以路由到任何 kube-apiserver 实例的负载均衡器通信
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.31 版本（不支持 1.32 版本，因为它比 1.31 版本的 kube-apiserver 实例新）

kubectl

kubectl 在 kube-apiserver 的一个次要版本（较旧或较新）中支持。

例如：

• kube-apiserver 处于 1.32 版本
• kubectl 支持 1.33、1.32 和 1.31 版本

例如：

• kube-apiserver 实例处于 1.32 和 1.31 版本
• kubectl 支持 1.32 和 1.31 版本（其他版本将与 kube-apiserver 组件之一相差不止一个的次要版本）

支持的组件升级顺序

组件之间支持的版本偏差会影响必须升级组件的顺序。 本节介绍了将现有集群从 1.31 版本转换到 1.32 版本时必须升级组件的顺序。

作为一种可选方案，在准备升级时，Kubernetes 项目建议你执行以下操作， 有利于升级时包含尽可能多的回归和错误修复：

• 确保组件是当前次要版本的最新补丁版本。
• 将组件升级到目标次要版本的最新补丁版本。

例如，如果你正在运行版本 1.31， 请确保你使用的是最新的补丁版本。 然后，升级到 1.32 的最新补丁版本。

kube-apiserver

先决条件：

• 在单实例集群中，现有的 kube-apiserver 实例处于 1.31 版本
• 在 HA 集群中，所有 kube-apiserver 实例都处于 1.31 或 1.32 版本 （这确保了最老和最新的 kube-apiserver 实例之间的 1 个次要版本的最大偏差）
• 与此服务器通信的 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 实例的版本为 1.31 （这确保它们是不比现有 API 服务器版本还要新，并且在新 API 服务器版本的 1 个次要版本内）
• 所有节点上的 kubelet 实例都是 1.31 或 1.30 版本（这确保它们不比现有 API 服务器版本新，并且在新 API 服务器版本的 2 个次要版本内）
• 已注册的 admission webhook 能够处理新的 kube-apiserver 实例将发送给他们的数据：
  • ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象已更新以包含 1.32 中添加的任何新版本的 REST 资源 （或使用 v1.15+ 中可用的 matchPolicy: Equivalent 选项）
  • webhook 能够处理将发送给它们的任何新版本的 REST 资源， 以及添加到 1.32 中现有版本的任何新字段

将 kube-apiserver 升级到 1.32 版本

kube-controller-manager、kube-scheduler 和 cloud-controller-manager

先决条件：

• 与这些组件通信的 kube-apiserver 实例处于 1.32 版本 （在 HA 集群中，这些控制平面组件可以与集群中的任何 kube-apiserver 实例通信， 所有 kube-apiserver 实例必须在升级这些组件之前升级）

将 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 升级到 1.32 版本。 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 的升级顺序没有要求。 你可以按任意顺序升级这些组件，甚至可以同时升级这些组件。

kubelet

先决条件：

• 与 kubelet 通信的 kube-apiserver 实例处于 1.32 版本

可选择将 kubelet 实例升级到 版本 （或者它们可以留在 1.31 或 1.30 或 1.29 版本）

kube-proxy

前提条件：

• 与 kube-proxy 通信的 kube-apiserver 实例的版本是 1.32。 可以选择升级 kube-proxy 实例到 1.32 （或者它们可以保持在 1.31 或 1.30）