版本偏差策略

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

支持的版本

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

Kubernetes 项目为最近的三个次要版本 (1.33, 1.32, 1.31) 维护发布分支。Kubernetes 1.19 及更新版本大约获得 1 年的补丁支持。Kubernetes 1.18 及更旧版本大约获得 9 个月的补丁支持。

适用的修复，包括安全修复，可能会根据严重性和可行性被回迁到这三个发布分支。补丁版本会从这些分支中按固定的节奏发布，另外在需要时还会发布额外的紧急版本。

发布管理员 组负责此决定。

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

支持的版本偏差

kube-apiserver

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

示例

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

kubelet

• kubelet 不能比 kube-apiserver 新。
• kubelet 可以比 kube-apiserver 旧最多三个次要版本 (kubelet < 1.25 时，只能比 kube-apiserver 旧最多两个次要版本)。

示例

• kube-apiserver 版本为 1.33
• kubelet 支持的版本为 1.33, 1.32, 1.31 和 1.30

示例

• kube-apiserver 实例版本为 1.33 和 1.32
• kubelet 支持的版本为 1.32, 1.31 和 1.30 (不支持 1.33 是因为该版本会比版本为 1.32 的 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.33
• kube-proxy 支持的版本为 1.33, 1.32, 1.31 和 1.30

示例

• kube-apiserver 实例版本为 1.33 和 1.32
• kube-proxy 支持的版本为 1.32, 1.31 和 1.30 (不支持 1.33 是因为该版本会比版本为 1.32 的 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.33
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持的版本为 1.33 和 1.32

示例

• kube-apiserver 实例版本为 1.33 和 1.32
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 与可以路由到任何 kube-apiserver 实例的负载均衡器通信
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支持的版本为 1.32 (不支持 1.33 是因为该版本会比版本为 1.32 的 kube-apiserver 实例新)。

kubectl

kubectl 支持的版本与 kube-apiserver 在一个次要版本之内 (可旧可新)。

示例

• kube-apiserver 版本为 1.33
• kubectl 支持的版本为 1.34, 1.33 和 1.32

示例

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

支持的组件升级顺序

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

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

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

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

kube-apiserver

前提条件

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

将 kube-apiserver 升级到 1.33

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

前提条件

• 这些组件通信的 kube-apiserver 实例版本为 1.33 (在 HA 集群中，如果这些控制平面组件可以与集群中的任何 kube-apiserver 实例通信，则必须先升级所有 kube-apiserver 实例，然后才能升级这些组件)。

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

kubelet

前提条件

• kubelet 通信的 kube-apiserver 实例版本为 1.33

可选地将 kubelet 实例升级到 1.33 (或者可以保留在 1.32, 1.31 或 1.30 版本)

kube-proxy

前提条件

• kube-proxy 通信的 kube-apiserver 实例版本为 1.33

可选地将 kube-proxy 实例升级到 1.33 (或者可以保留在 1.32, 1.31 或 1.30 版本)