版本偏差策略

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

支持的版本

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

Kubernetes 项目为最近的三个次要版本（1.30、1.29、1.28）维护发布分支。Kubernetes 1.19 及更高版本 大约提供 1 年的补丁支持。Kubernetes 1.18 及更早版本大约提供了 9 个月的补丁支持。

适用的修复程序（包括安全修复程序）可能会反向移植到这三个发布分支，具体取决于严重程度和可行性。补丁版本会以 常规节奏 从这些分支中发布，并在需要时发布额外的紧急版本。

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

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

支持的版本偏差

kube-apiserver

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

示例

• 最新的 kube-apiserver 为 1.30
• 其他 kube-apiserver 实例支持 1.30 和 1.29

kubelet

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

示例

• kube-apiserver 为 1.30
• kubelet 支持 1.30、1.29、1.28 和 1.27

示例

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

示例

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

示例

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

kubectl

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

示例

• kube-apiserver 为 1.30
• kubectl 支持 1.31、1.30 和 1.29

示例

• kube-apiserver 实例为 1.30 和 1.29
• kubectl 支持 1.30 和 1.29（其他版本将与其中一个 kube-apiserver 组件相差多个次要版本）

支持的组件升级顺序

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

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

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

例如，如果您运行的是版本 1.29，请确保您使用的是最新的补丁版本。然后，升级到 1.30 的最新补丁版本。

kube-apiserver

先决条件

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

将 kube-apiserver 升级到 1.30

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

先决条件

• 这些组件与其通信的 kube-apiserver 实例为 1.30（在这些控制平面组件可以与集群中的任何 kube-apiserver 实例通信的 HA 集群中，必须先升级所有 kube-apiserver 实例，然后再升级这些组件）

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

kubelet

先决条件

• kubelet 与其通信的 kube-apiserver 实例为 1.30

（可选）将 kubelet 实例升级到 1.30（或者可以保留为 1.29、1.28 或 1.27）

kube-proxy

先决条件

• kube-proxy 与其通信的 kube-apiserver 实例为 1.30

（可选）将 kube-proxy 实例升级到 1.30（或者可以保留为 1.29、1.28 或 1.27）