版本支持策略
Kubernetes 版本號格式為 x.y.z，其中 x 為大版本號，y 為小版本號，z 為補丁版本號。 版本號格式遵循 Semantic Versioning 規則。
Kubernetes 項目會維護最近的三個小版本分支（1.21, 1.20, 1.19）。 Kubernetes 1.19 及更高的版本將獲得大約1年的補丁支持。 Kubernetes 1.18 及更早的版本獲得大約9個月的補丁支持。
一些 bug 修復，包括安全修復，取決於其嚴重性和可行性，有可能會反向合並到這三個發布分支。 補丁版本會定期 或根據需要從這些分支中發布。 最終是否發布是由 發布管理者 來決定的。
版本偏差策略
kube-apiserver
在 高可用（HA）集群 中， 多個 kube-apiserver 實例小版本號最多差1。
例如：
- 最新的 kube-apiserver 版本號如果是 1.21
- 其他受支持的 kube-apiserver 版本號包括 1.21 和 1.20
kubelet
kubelet 版本號不能高於 kube-apiserver，最多可以比 kube-apiserver 低兩個小版本。
例如：
- kube-apiserver 版本號如果是 1.21
- 受支持的的 kubelet 版本將包括 1.21、 1.20 和 1.19
說明： 如果 HA 集群中多個 kube-apiserver 實例版本號不一致，相應的 kubelet 版本號可選范圍也要減小。
例如：
- 如果 kube-apiserver 實例同時存在 1.21 和 1.20
- kubelet 的受支持版本將是 1.20 和 1.19 （1.21 不再支持，因為它比 1.20 版本的 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.21
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本支持 1.21 和 1.20
說明： 如果在 HA 集群中，多個 kube-apiserver 實例版本號不一致，他們也可以跟 任意一個 kube-apiserver 實例通信（例如，通過 load balancer）， 但 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本可用范圍會相應的減小。
例如：
- kube-apiserver 實例同時存在 1.21 和 1.20 版本
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可以通過 load balancer 與所有的 kube-apiserver 通信
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 可選版本為 1.20 （1.21 不再支持，因為它比 1.20 版本的 kube-apiserver 更新）
kubectl
kubectl 可以比 kube-apiserver 高一個小版本，也可以低一個小版本。
例如：
- 如果 kube-apiserver 當前是 1.21 版本
- kubectl 則支持 1.22、1.21 和 1.20
說明： 如果 HA 集群中的多個 kube-apiserver 實例版本號不一致，相應的 kubectl 可用版本范圍也會減小。
例如：
- kube-apiserver 多個實例同時存在 1.21 和 1.20
- kubectl 可選的版本為 1.21 和 1.20（其他版本不再支持， 因為它會比其中某個 kube-apiserver 實例高或低一個小版本）
支持的組件升級次序
組件之間支持的版本偏差會影響組件升級的順序。 本節描述組件從版本 1.20 到 1.21 的升級次序。
kube-apiserver
前提條件：
- 單實例集群中，kube-apiserver 實例版本號須是 1.20
- 高可用（HA）集群中，所有的 kube-apiserver 實例版本號必須是 1.20 或 1.21 （確保滿足最新和最舊的實例小版本號相差不大於1）
- kube-controller-manager、kube-scheduler 和 cloud-controller-manager 版本號必須為 1.20 （確保不高於 API server 的版本，且版本號相差不大於1）
- kubelet 實例版本號必須是 1.20 或 1.19（確保版本號不高於 API server，且版本號相差不大於2）
- 注冊的 admission 插件必須能夠處理新的 kube-apiserver 實例發送過來的數據：
- ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 對象必須升級到可以處理 1.21 版本新加的 REST 資源（或使用 1.15 版本提供的 matchPolicy: Equivalent 選項）
- 插件可以處理任何 1.21 版本新的 REST 資源數據和新加的字段
升級 kube-apiserver 到 1.21
說明：根據 API 棄用策略 和 API 變更指南， kube-apiserver 不能跨小版本號升級，即使是單實例集群也不可以。
kube-controller-manager、kube-scheduler 和 cloud-controller-manager
前提條件：
- kube-apiserver 實例必須為 1.21 （HA 集群中，所有的kube-apiserver 實例必須在組件升級前完成升級）
升級 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 到 1.21
kubelet
前提條件：
- kube-apiserver 實例必須為 1.21 版本
kubelet 可以升級到 1.21（或者停留在 1.20 或 1.19）
說明：在對 kubelet 執行次版本升級時，先騰空 節點上的 Pods。 目前不支持原地升級 kubelet 的次版本。
警告：集群中 kubelet 版本號不建議比 kube-apiserver 低兩個版本號：
- 它們必須升級到與 kube-apiserver 相差不超過 1 個小版本，才可以升級其他控制面組件
- 有可能使用低於 3 個在維護的小版本
kube-proxy
- kube-proxy 必須與節點上的 kubelet 的小版本相同
- kube-proxy 一定不能比 kube-apiserver 小版本更新
- kube-proxy 最多只能比 kube-apiserver 早兩個小版本
例如：
如果 kube-proxy 的版本是 1.19：
- kubelet 版本必須相同，也是 1.19
- kube-apiserver 版本必須在 1.19 到 1.21 之間（閉區間）