版本偏差策略

本文档描述了各种 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 补丁发布 页面。

支持的版本倾斜

kube-apiserver

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

示例

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

kubelet

• kubelet 版本不得高于 kube-apiserver。
• kubelet 版本可以比 kube-apiserver 低最多三个次版本号（kubelet < 1.25 只能比 kube-apiserver 低最多两个次版本号）。

示例

• kube-apiserver 是 1.35
• kubelet 支持版本 1.35、1.34、1.33 和 1.32

示例

• kube-apiserver 实例是 1.35 和 1.34
• kubelet 支持版本 1.34、1.33 和 1.32（1.35 不受支持，因为这将高于版本为 1.34 的 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.35
• kube-proxy 支持版本 1.35、1.34、1.33 和 1.32

示例

• kube-apiserver 实例是 1.35 和 1.34
• kube-proxy 支持版本 1.34、1.33 和 1.32（1.35 不受支持，因为这将高于版本为 1.34 的 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.35
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持版本 1.35 和 1.34

示例

• 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

kubectl 版本可以比 kube-apiserver 高或低一个次版本号。

示例

• kube-apiserver 是 1.35
• kubectl 支持版本 1.36、1.35 和 1.34

示例

• kube-apiserver 实例是 1.35 和 1.34
• kubectl 支持版本 1.35 和 1.34（其他版本将与其中一个 kube-apiserver 组件倾斜超过一个次版本号）

支持的组件升级顺序

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

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

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

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

kube-apiserver

先决条件

• 在单实例集群中，现有的 kube-apiserver 实例是 1.34
• 在 HA 集群中，所有 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 个次版本号）
• 已注册的准入 webhook 能够处理新的 kube-apiserver 实例将发送给它们的数据
  • ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象已更新，以包含 1.35 中添加的 REST 资源的新版本（或使用 v1.15+ 中提供的 matchPolicy: Equivalent 选项）
  • webhook 能够处理将发送给它们的 REST 资源的任何新版本，以及 1.35 中添加到现有版本的任何新字段

将 kube-apiserver 升级到 1.35

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

先决条件

• 这些组件通信的 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

先决条件

• kubelet 通信的 kube-apiserver 实例是 1.35

可选地将 kubelet 实例升级到 1.35（或者可以将其保留在 1.34、1.33 或 1.32）

kube-proxy

先决条件

• kube-proxy 通信的 kube-apiserver 实例是 1.35

可以选择将 kube-proxy 实例升级到 1.35（或者可以保持在 1.34、1.33 或 1.32）