版本偏差策略

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

支持的版本

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

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

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

发布经理（Release Managers）组负责此项决策。

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

支持的版本偏差

kube-apiserver

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

示例

• 最新 kube-apiserver 为 1.36
• 支持其他 kube-apiserver 实例为 1.36 和 1.35

kubelet

• kubelet 的版本不得高于 kube-apiserver。
• kubelet 最多可比 kube-apiserver 晚三个次要版本（kubelet < 1.25 最多仅可比 kube-apiserver 晚两个次要版本）。

示例

• kube-apiserver 为 1.36
• kubelet 支持 1.36、1.35、1.34 和 1.33

示例

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

示例

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

示例

• kube-apiserver 实例为 1.36 和 1.35
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 与一个可以将流量路由到任何 kube-apiserver 实例的负载均衡器进行通信
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 1.35（不支持 1.36，因为这会高于版本为 1.35 的 kube-apiserver 实例）

kubectl

kubectl 支持比 kube-apiserver 早或晚一个次要版本。

示例

• kube-apiserver 为 1.36
• kubectl 支持 1.37、1.36 和 1.35

示例

• kube-apiserver 实例为 1.36 和 1.35
• kubectl 支持 1.36 和 1.35（其他版本与其中一个 kube-apiserver 组件的偏差将超过一个次要版本）

支持的组件升级顺序

各组件之间支持的版本偏差对组件的升级顺序有影响。本节描述了将现有集群从 1.35 版本过渡到 1.36 版本时必须遵循的组件升级顺序。

在准备升级时，Kubernetes 项目建议您选择性地执行以下操作，以便在升级过程中尽可能利用到回归测试和错误修复：

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

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

kube-apiserver

前提条件

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

将 kube-apiserver 升级到 1.36

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

前提条件

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

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

kubelet

前提条件

• kubelet 所通信的 kube-apiserver 实例均为 1.36

可选择将 kubelet 实例升级到 1.36（也可以保持为 1.35、1.34 或 1.33）

kube-proxy

前提条件

• kube-proxy 所通信的 kube-apiserver 实例均为 1.36

可选择将 kube-proxy 实例升级到 1.36（也可以保持为 1.35、1.34 或 1.33）