版本偏差策略

本文档描述了各種 Kubernetes 組件之間支援的最大版本偏差。特定的叢集部署工具可能會對版本偏差施加額外的限制。

支援的版本

Kubernetes 版本以 x.y.z 表示，其中 x 是主要版本，y 是次要版本，而 z 是修補程式版本，遵循 語意化版本控制 術語。如需更多資訊，請參閱 Kubernetes 發行版本控制。

Kubernetes 專案維護最近三個次要版本（1.32、1.31、1.30）的發行分支。Kubernetes 1.19 及更新版本獲得 約 1 年的修補程式支援。Kubernetes 1.18 及更舊版本獲得約 9 個月的修補程式支援。

適用的修復程式，包括安全性修復程式，可能會回溯移植到這三個發行分支，具體取決於嚴重性和可行性。修補程式版本是從這些分支以 常規節奏 加上額外的緊急版本（在需要時）切割出來的。

發行管理員 群組擁有此決策權。

如需更多資訊，請參閱 Kubernetes 修補程式版本 頁面。

支援的版本偏差

kube-apiserver

在 高可用性 (HA) 叢集 中，最新和最舊的 kube-apiserver 實例必須在一個次要版本之內。

範例

• 最新的 kube-apiserver 版本為 1.32
• 其他 kube-apiserver 實例支援 1.32 和 1.31

kubelet

• kubelet 不得比 kube-apiserver 新。
• kubelet 可能比 kube-apiserver 舊最多三個次要版本（kubelet < 1.25 可能僅比 kube-apiserver 舊最多兩個次要版本）。

範例

• kube-apiserver 的版本為 1.32
• kubelet 支援 1.32、1.31、1.30 和 1.29

範例

• kube-apiserver 實例的版本為 1.32 和 1.31
• kubelet 支援 1.31、1.30 和 1.29 (1.32 不受支援，因為它會比版本為 1.31 的 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.32
• kube-proxy 支援 1.32、1.31、1.30 和 1.29

範例

• kube-apiserver 實例的版本為 1.32 和 1.31
• kube-proxy 支援 1.31、1.30 和 1.29 (1.32 不受支援，因為它會比版本為 1.31 的 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.32
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支援 1.32 和 1.31

範例

• kube-apiserver 實例的版本為 1.32 和 1.31
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 與可以路由到任何 kube-apiserver 實例的負載平衡器通訊
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支援 1.31 (1.32 不受支援，因為它會比版本為 1.31 的 kube-apiserver 實例新)

kubectl

kubectl 在 kube-apiserver 的一個次要版本範圍內（舊版或新版）都受支援。

範例

• kube-apiserver 的版本為 1.32
• kubectl 支援 1.33、1.32 和 1.31

範例

• kube-apiserver 實例的版本為 1.32 和 1.31
• kubectl 支援 1.32 和 1.31（其他版本會比其中一個 kube-apiserver 組件的版本偏差超過一個次要版本）

支援的組件升級順序

組件之間支援的版本偏差會影響組件必須升級的順序。本節描述了將現有叢集從版本 1.31 轉換到版本 1.32 必須升級組件的順序。

或者，在準備升級時，Kubernetes 專案建議您執行以下操作，以便在升級期間從盡可能多的迴歸和錯誤修復中受益

• 確保組件位於目前次要版本的最新修補程式版本上。
• 將組件升級到目標次要版本的最新修補程式版本。

例如，如果您執行的是 1.31 版本，請確保您位於最新的修補程式版本。然後，升級到 1.32 的最新修補程式版本。

kube-apiserver

先決條件

• 在單一實例叢集中，現有的 kube-apiserver 實例為 1.31
• 在 HA 叢集中，所有 kube-apiserver 實例的版本為 1.31 或 1.32（這確保了最舊和最新的 kube-apiserver 實例之間的最大偏差為 1 個次要版本）
• 與此伺服器通訊的 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 實例的版本為 1.31（這確保它們不比現有的 API 伺服器版本新，並且在新 API 伺服器版本的一個次要版本範圍內）
• 所有節點上的 kubelet 實例的版本為 1.31 或 1.30（這確保它們不比現有的 API 伺服器版本新，並且在新 API 伺服器版本的兩個次要版本範圍內）
• 已註冊的准入 Webhook 能夠處理新的 kube-apiserver 實例將發送給它們的資料
  • ValidatingWebhookConfiguration 和 MutatingWebhookConfiguration 物件已更新，以包含在 1.32 中新增的任何新版本的 REST 資源（或使用 v1.15+ 中提供的 matchPolicy: Equivalent 選項）
  • Webhook 能夠處理將發送給它們的任何新版本的 REST 資源，以及在 1.32 中新增到現有版本的任何新欄位

將 kube-apiserver 升級到 1.32

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

先決條件

• 這些組件通訊的 kube-apiserver 實例的版本為 1.32（在 HA 叢集中，其中這些控制平面組件可以與叢集中的任何 kube-apiserver 實例通訊，所有 kube-apiserver 實例都必須在升級這些組件之前升級）

將 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 升級到 1.32。kube-controller-manager、kube-scheduler 和 cloud-controller-manager 之間沒有必要的升級順序。您可以按任何順序甚至同時升級這些組件。

kubelet

先決條件

• kubelet 通訊的 kube-apiserver 實例的版本為 1.32

選擇性地將 kubelet 實例升級到 1.32（或者它們可以保留在 1.31、1.30 或 1.29）

kube-proxy

先決條件

• kube-proxy 通訊的 kube-apiserver 實例的版本為 1.32

選擇性地將 kube-proxy 實例升級到 1.32（或者它們可以保留在 1.31、1.30 或 1.29）