98 lines
No EOL
4.9 KiB
Markdown
98 lines
No EOL
4.9 KiB
Markdown
## 版本支持策略
|
||
Kubernetes 版本号格式为 x.y.z，其中 x 为大版本号，y 为小版本号，z 为补丁版本号。 版本号格式遵循 Semantic Versioning 规则。 更多信息，请参阅 Kubernetes 发布版本。
|
||
|
||
## 版本偏差策略
|
||
### kube-apiserver
|
||
在 高可用（HA）集群 中， 多个 kube-apiserver 实例小版本号最多差1。
|
||
|
||
例如：
|
||
|
||
最新的 kube-apiserver 版本号如果是 1.19
|
||
则受支持的 kube-apiserver 版本号包括 1.19 和 1.18
|
||
|
||
### kubelet
|
||
kubelet 版本号不能高于 kube-apiserver，最多可以比 kube-apiserver 低两个小版本。
|
||
|
||
例如：
|
||
|
||
kube-apiserver 版本号如果是 1.19
|
||
受支持的的 kubelet 版本将包括 1.19、1.18 和 1.17
|
||
说明： 如果 HA 集群中多个 kube-apiserver 实例版本号不一致，相应的 kubelet 版本号可选范围也要减小。
|
||
例如：
|
||
|
||
如果 kube-apiserver 实例同时存在 1.19 和 1.18
|
||
kubelet 的受支持版本将是 1.18 和 1.17 （1.19 不再支持，因为它比 1.18 版本的 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.19
|
||
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本支持 1.19 和 1.18
|
||
说明： 如果在 HA 集群中，多个 kube-apiserver 实例版本号不一致，他们也可以跟任意一个 kube-apiserver 实例通信（例如，通过 load balancer）， 但 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本可用范围会相应的减小。
|
||
例如：
|
||
|
||
kube-apiserver 实例同时存在 1.19 和 1.18 版本
|
||
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可以通过 load balancer 与所有的 kube-apiserver 通信
|
||
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可选版本为 1.18 （1.19 不再支持，因为它比 1.18 版本的 kube-apiserver 更新）
|
||
|
||
### kubectl
|
||
kubectl 可以比 kube-apiserver 高一个小版本，也可以低一个小版本。
|
||
|
||
例如：
|
||
|
||
如果 kube-apiserver 当前是 1.19 版本
|
||
kubectl 则支持 1.20、1.19 和 1.18
|
||
说明： 如果 HA 集群中的多个 kube-apiserver 实例版本号不一致，相应的 kubectl 可用版本范围也会减小。
|
||
例如：
|
||
|
||
kube-apiserver 多个实例同时存在 1.19 和 1.18
|
||
kubectl 可选的版本为 1.19 和 1.18（其他版本不再支持，因为它会比其中某个 kube-apiserver 实例高或低一个小版本）
|
||
|
||
## 支持的组件升级次序
|
||
组件之间支持的版本偏差会影响组件升级的顺序。 本节描述组件从版本 1.18 到 1.19 的升级次序。
|
||
|
||
### kube-apiserver
|
||
前提条件：
|
||
|
||
单实例集群中，kube-apiserver 实例版本号须是 1.18
|
||
高可用（HA）集群中，所有的 kube-apiserver 实例版本号必须是 1.18 或 1.19（确保满足最新和最旧的实例小版本号相差不大于1）
|
||
kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本号必须为 1.18（确保不高于 API server 的版本，且版本号相差不大于1）
|
||
kubelet 实例版本号必须是 1.18 或 1.17（确保版本号不高于 API server，且版本号相差不大于2）
|
||
注册的 admission 插件必须能够处理新的 kube-apiserver 实例发送过来的数据：
|
||
ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 对象必须升级到可以处理 1.19 版本新加的 REST 资源（或使用 1.15 版本提供的 matchPolicy: Equivalent 选项）
|
||
插件可以处理任何 1.19 版本新的 REST 资源数据和新加的字段
|
||
升级 kube-apiserver 到 1.19
|
||
|
||
说明：
|
||
根据 API 弃用策略 和 API 变更指南， kube-apiserver 不能跨小版本号升级，即使是单实例集群也不可以。
|
||
|
||
### kube-controller-manager、kube-scheduler 和 cloud-controller-manager
|
||
前提条件：
|
||
|
||
kube-apiserver 实例必须为 1.19 （HA 集群中，所有的kube-apiserver 实例必须在组件升级前完成升级）
|
||
升级 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 到 1.19
|
||
|
||
### kubelet
|
||
前提条件：
|
||
|
||
kube-apiserver 实例必须为 1.19 版本
|
||
kubelet 可以升级到 1.19（或者停留在 1.18 或 1.17）
|
||
|
||
警告：
|
||
集群中 kubelet 版本号不建议比 kube-apiserver 低两个版本号：
|
||
|
||
它们必须升级到与 kube-apiserver 相差不超过 1 个小版本，才可以升级其他控制面组件
|
||
有可能使用低于 3 个在维护的小版本
|
||
|
||
### kube-proxy
|
||
kube-proxy 必须与节点上的 kubelet 的小版本相同
|
||
kube-proxy 一定不能比 kube-apiserver 小版本更新
|
||
kube-proxy 最多只能比 kube-apiserver 早两个小版本
|
||
例如：
|
||
|
||
如果 kube-proxy 的版本是 1.17：
|
||
|
||
kubelet 版本必须相同，也是 1.17
|
||
kube-apiserver 版本必须在 1.17 到 1.19 之间（闭区间） |