版本偏差策略

本文档描述了 Kubernetes 各组件支持的最大版本偏差。具体的集群部署工具可能会对版本偏差施加额外的限制。

支持的版本

Kubernetes 版本表示为 x.y.z，其中 x 是主版本，y 是次版本，z 是补丁版本，遵循 语义版本控制 术语。有关更多信息，请参阅 Kubernetes 版本控制。

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

根据严重程度和可行性，适用的修复程序（包括安全修复程序）可能会被回溯到这三个发布分支。补丁版本会按照 固定节奏 从这些分支中发布，并在需要时发布额外的紧急版本。

发布经理 组拥有此决定权。

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

支持的版本偏差

kube-apiserver

在 高可用 (HA) 集群 中，最新和最旧的 kube-apiserver 实例必须在一个次版本之内。

示例

• 最新的 kube-apiserver 版本为 1.34
• 其他 kube-apiserver 实例支持的版本为 1.34 和 1.33

kubelet

• kubelet 的版本不能比 kube-apiserver 新。
• kubelet 可以比 kube-apiserver 最多旧三个次版本（kubelet < 1.25 最多只能比 kube-apiserver 旧两个次版本）。

示例

• kube-apiserver 版本为 1.34
• kubelet 支持的版本为 1.34, 1.33, 1.32 和 1.31

示例

• kube-apiserver 实例的版本为 1.34 和 1.33
• kubelet 支持的版本为 1.33, 1.32 和 1.31（不支持 1.34，因为这将比版本 1.33 的 kube-apiserver 实例新）

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.34
• kube-proxy 支持的版本为 1.34, 1.33, 1.32 和 1.31

示例

• kube-apiserver 实例的版本为 1.34 和 1.33
• kube-proxy 支持的版本为 1.33, 1.32 和 1.31（不支持 1.34，因为这将比版本 1.33 的 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.34
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持的版本为 1.34 和 1.33

示例

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

kubectl

kubectl 支持的版本与 kube-apiserver 相差一个次版本（旧或新）。

示例

• kube-apiserver 版本为 1.34
• kubectl 支持的版本为 1.35, 1.34 和 1.33

示例

• kube-apiserver 实例的版本为 1.34 和 1.33
• kubectl 支持的版本为 1.34 和 1.33（其他版本将与其中一个 kube-apiserver 组件相差一个以上的次版本）

支持的组件升级顺序

组件之间支持的版本偏差对组件必须升级的顺序有影响。本节描述了将现有集群从版本 1.33 升级到版本 1.34 时必须升级组件的顺序。

（可选）在准备升级时，Kubernetes 项目建议您执行以下操作，以便在升级过程中从尽可能多的回归和错误修复中受益

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

例如，如果您正在运行版本 1.33，请确保您位于最新的补丁版本。然后，升级到 1.34 的最新补丁版本。

kube-apiserver

先决条件

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

将 kube-apiserver 升级到 1.34

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

先决条件

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

将 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 升级到 1.34。kube-controller-manager、kube-scheduler 和 cloud-controller-manager 之间没有强制的升级顺序。您可以按任何顺序升级这些组件，甚至可以同时升级。

kubelet

先决条件

• kubelet 通信的 kube-apiserver 实例的版本为 1.34

（可选）将 kubelet 实例升级到 1.34（或它们可以保留在 1.33、1.32 或 1.31）

kube-proxy

先决条件

• kube-proxy 通信的 kube-apiserver 实例的版本为 1.34

（可选）将 kube-proxy 实例升级到 1.34（或它们可以保留在 1.33、1.32 或 1.31）