Kubernetes 版本及版本倾斜支持策略

Kubernetes, 容器云 / 作者：

关于Kubernetes 各组件之间版本倾斜支持策略。 特定的集群部署工具可能会有额外的限制。

版本支持策略

Kubernetes 版本号格式为 x.y.z，其中 x 为大版本号，y 为小版本号，z 为补丁版本号。 版本号格式遵循 Semantic Versioning 规则。 更多信息，请参阅 Kubernetes Release Versioning。

Kubernetes 项目会维护最近的三个小版本分支。

一些 bug 修复，包括安全修复，根据其安全性和可用性，有可能会回合到这些分支。 补丁版本会定期或根据需要从这些分支中发布。 最终是否发布是由patch release team 来决定的。Patch release team同时也是release managers. 如需了解更多信息，请查看 Kubernetes Patch releases.

小版本大约每3个月发布一个，所以每个小版本分支会维护9个月。

版本倾斜策略

kube-apiserver

在 高可用（HA）集群 中， 多个 kube-apiserver 实例小版本号最多差1。

例如：

  • 最新的 kube-apiserver 版本号如果是 1.13
  • 其他 kube-apiserver 版本号只能是 1.13 或 1.12

kubelet

kubelet 版本号不能高于 kube-apiserver，最多可以比 kube-apiserver 低两个小版本。

例如：

  • kube-apiserver 版本号如果是 1.13
  • kubelet 只能是 1.13 、 1.12 和 1.11
说明： 如果 HA集群中多个 `kube-apiserver` 实例版本号不一致，相应的 `kubelet` 版本号可选范围也要减小。

例如：

  • 如果 kube-apiserver 的多个实例同时存在 1.13 和 1.12
  • kubelet 只能是 1.12 或 1.11（1.13 不再支持，因为它比1.12版本的 kube-apiserver 更新）

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

kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本不能高于 kube-apiserver 版本号。 最好它们的版本号与 kube-apiserver 保持一致，但允许比 kube-apiserver 低一个小版本（为了支持在线升级）。

例如：

  • 如果 kube-apiserver 版本号为 1.13
  • kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本支持 1.13 和 1.12
说明： 如果在 HA 集群中，多个 `kube-apiserver` 实例版本号不一致，他们也可以跟任意一个 `kube-apiserver` 实例通信（例如，通过 load balancer）， 但 `kube-controller-manager`、`kube-scheduler` 和 `cloud-controller-manager` 版本可用范围会相应的减小。

例如：

  • kube-apiserver 实例同时存在 1.13 和 1.12 版本
  • kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可以通过 load balancer 与所有的 kube-apiserver 通信
  • kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可选版本为 1.12（1.13 不再支持，因为它比 1.12 版本的 kube-apiserver 更新）

kubectl

kubectl 可以比 kube-apiserver 高一个小版本，也可以低一个小版本。

例如：

  • 如果 kube-apiserver 当前是 1.13 版本
  • kubectl 则支持 1.14 、1.13 和 1.12
说明： 如果 HA 集群中的多个 `kube-apiserver` 实例版本号不一致，相应的 `kubectl` 可用版本范围也会减小。

例如：

  • kube-apiserver 多个实例同时存在 1.13 和 1.12
  • kubectl 可选的版本为 1.13 和 1.12（其他版本不再支持，因为它会比其中某个 kube-apiserver 实例高或低一个小版本）

支持的组件升级次序

组件之间支持的版本倾斜会影响组件升级的顺序。 本节描述组件从版本 1.n 到 1.(n+1) 的升级次序。

kube-apiserver

前提条件：

  • 单实例集群时，kube-apiserver 实例版本号须是 1.n
  • HA 集群时，所有的 kube-apiserver 实例版本号必须是 1.n 或 1.(n+1)（确保满足最新和最旧的实例小版本号相差不大于1）
  • kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本号必须为 1.n（确保不高于 API server 的版本，且版本号相差不大于1）
  • kubelet 实例版本号必须是 1.n 或 1.(n-1)（确保版本号不高于 API server，且版本号相差不大于2）
  • 注册的 admission 插件必须能够处理新的 kube-apiserver 实例发送过来的数据：
    • ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象必须升级到可以处理 1.(n+1) 版本新加的 REST 资源(或使用1.15版本提供的 matchPolicy: Equivalent 选项)
    • 插件可以处理任何 1.(n+1) 版本新的 REST 资源数据和新加的字段

升级 kube-apiserver 到 1.(n+1)

说明： 跟据 [API deprecation](/docs/reference/using-api/deprecation-policy/) 和 [API change guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) 规则， `kube-apiserver` 不能跨小版本号升级，即使是单实例集群也不可以。

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

前提条件：

  • kube-apiserver 实例必须为 1.(n+1) （HA 集群中，所有的kube-apiserver 实例必须在组件升级前完成升级）

升级 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 到 1.(n+1)

kubelet

前提条件：

  • kube-apiserver 实例必须为 1.(n+1) 版本

kubelet 可以升级到 1.(n+1)（或者停留在 1.n 或 1.(n-1)）

警告： 集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号：

  • 他们必须升级到与 kube-apiserver 相差不超过1个小版本，才可以升级其他控制面组件
  • 有可能使用低于3个在维护的小版本

发表评论