版本偏差策略

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

支持的版本

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

Kubernetes 项目为最近三个次要版本（1.31、1.30、1.29）维护发布分支。Kubernetes 1.19 及更新版本会收到 大约一年的修补程序支持。Kubernetes 1.18 及更早版本收到大约 9 个月的修补程序支持。

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

此决定的所有权属于 发布经理 小组。

有关更多信息，请参阅 Kubernetes 修补程序版本 页面。

支持的版本偏差

kube-apiserver

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

示例

• 最新的 kube-apiserver 版本为 **1.31**
• 其他 kube-apiserver 实例支持 **1.31** 和 **1.30** 版本

kubelet

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

示例

• kube-apiserver 版本为 **1.31**
• kubelet 支持 **1.31**、**1.30**、**1.29** 和 **1.28** 版本

示例

• kube-apiserver 实例版本为 **1.31** 和 **1.30**
• kubelet 支持 **1.30**、**1.29** 和 **1.28** 版本（不支持 **1.31**，因为它将比版本为 **1.30** 的 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.31**
• kube-proxy 支持 **1.31**、**1.30**、**1.29** 和 **1.28** 版本

示例

• kube-apiserver 实例版本为 **1.31** 和 **1.30**
• kube-proxy 支持 **1.30**、**1.29** 和 **1.28** 版本（不支持 **1.31**，因为它将比版本为 **1.30** 的 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.31**
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持 **1.31** 和 **1.30** 版本

示例

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

kubectl

kubectl 支持 kube-apiserver 的一个次要版本（更低或更高）范围内。

示例

• kube-apiserver 版本为 **1.31**
• kubectl 支持 **1.32**、**1.31** 和 **1.30** 版本

示例

• kube-apiserver 实例版本为 **1.31** 和 **1.30**
• kubectl 支持 **1.31** 和 **1.30** 版本（其他版本将比其中一个 kube-apiserver 组件偏差超过一个次要版本）

支持的组件升级顺序

组件之间支持的版本偏差会影响必须升级组件的顺序。本节描述必须升级组件的顺序，以将现有集群从版本 **1.30** 迁移到版本 **1.31**。

可选地，在准备升级时，Kubernetes 项目建议您执行以下操作，以便在升级期间尽可能多地利用回归和错误修复

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

例如，如果您运行的是 1.30 版本，请确保您处于最新修补程序版本。然后，升级到 1.31 的最新修补程序版本。

kube-apiserver

先决条件

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

将 kube-apiserver 升级到 **1.31**

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

先决条件

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

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

kubelet

先决条件

• kubelet 与之通信的 kube-apiserver 实例的版本为 **1.31**

可选地将 kubelet 实例升级到 **1.31**（或者可以保留在 **1.30**、**1.29** 或 **1.28** 版本）

kube-proxy

先决条件

• kube-proxy 与之通信的 kube-apiserver 实例的版本为 **1.31**

可选地将 kube-proxy 实例升级到 **1.31**（或者可以保留在 **1.30**、**1.29** 或 **1.28** 版本）