Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
本文描述 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个月。
In highly-available (HA) clusters, the newest and oldest kube-apiserver
instances must be within one minor version.
在 高可用(HA)集群 中,
多个 kube-apiserver
实例小版本号最多差1。
例如:
kube-apiserver
版本号如果是 1.13kube-apiserver
版本号只能是 1.13 或 1.12kubelet
版本号不能高于 kube-apiserver
,最多可以比 kube-apiserver
低两个小版本。
例如:
kube-apiserver
版本号如果是 1.13kubelet
只能是 1.13 、 1.12 和 1.11注意: 如果 HA集群中多个 `kube-apiserver` 实例版本号不一致,相应的 `kubelet` 版本号可选范围也要减小。
例如:
kube-apiserver
的多个实例同时存在 1.13 和 1.12kubelet
只能是 1.12 或 1.11(1.13 不再支持,因为它比1.12版本的 kube-apiserver
更新)kube-controller-manager
、kube-scheduler
和 cloud-controller-manager
版本不能高于 kube-apiserver
版本号。
最好它们的版本号与 kube-apiserver
保持一致,但允许比 kube-apiserver
低一个小版本(为了支持在线升级)。
例如:
kube-apiserver
版本号为 1.13kube-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
可以比 kube-apiserver
高一个小版本,也可以低一个小版本。
例如:
kube-apiserver
当前是 1.13 版本kubectl
则支持 1.14 、1.13 和 1.12注意: 如果 HA 集群中的多个 `kube-apiserver` 实例版本号不一致,相应的 `kubectl` 可用版本范围也会减小。
例如:
kube-apiserver
多个实例同时存在 1.13 和 1.12kubectl
可选的版本为 1.13 和 1.12(其他版本不再支持,因为它会比其中某个 kube-apiserver
实例高或低一个小版本)组件之间支持的版本倾斜会影响组件升级的顺序。 本节描述组件从版本 1.n 到 1.(n+1) 的升级次序。
前提条件:
kube-apiserver
实例版本号须是 1.nkube-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)kube-apiserver
实例发送过来的数据:
ValidatingWebhookConfiguration
和 MutatingWebhookConfiguration
对象必须升级到可以处理 1.(n+1) 版本新加的 REST 资源(或使用1.15版本提供的 matchPolicy: Equivalent
选项)升级 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-apiserver
实例必须为 1.(n+1) (HA 集群中,所有的kube-apiserver
实例必须在组件升级前完成升级)升级 kube-controller-manager
、kube-scheduler
和 cloud-controller-manager
到 1.(n+1)
前提条件:
kube-apiserver
实例必须为 1.(n+1) 版本kubelet
可以升级到 1.(n+1)(或者停留在 1.n 或 1.(n-1))
警告: 集群中 `kubelet` 版本号不建议比 `kube-apiserver` 低两个版本号:
- 他们必须升级到与
kube-apiserver
相差不超过1个小版本,才可以升级其他控制面组件- 有可能使用低于3个在维护的小版本