版本偏差策略

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

支持的版本

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

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

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

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

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

支持的版本偏差

kube-apiserver

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

示例

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

kubelet

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

示例

• kube-apiserver 版本为 1.32
• kubelet 支持的版本为 1.32、1.31、1.30 和 1.29

示例

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

示例

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

示例

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

kubectl

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

示例

• kube-apiserver 版本为 1.32
• kubectl 支持的版本为 1.33、1.32 和 1.31

示例

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

支持的组件升级顺序

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

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

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

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

kube-apiserver

先决条件

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

将 kube-apiserver 升级到 1.32

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

先决条件

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

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

kubelet

先决条件

• kubelet 与其通信的 kube-apiserver 实例的版本为 1.32

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

kube-proxy

先决条件

• kube-proxy 与其通信的 kube-apiserver 实例的版本为 1.32

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