版本偏差策略

本文件描述了 Kubernetes 各元件支援的最大版本偏差。具體的叢集部署工具可能會對版本偏差施加額外的限制。

支援的版本

Kubernetes 版本表示為 x.y.z，其中 x 是主版本，y 是次版本，z 是補丁版本，遵循 語義版本控制 術語。有關更多資訊，請參閱 Kubernetes 版本控制。

Kubernetes 專案維護最近三個次版本（1.34、1.33、1.32）的釋出分支。Kubernetes 1.19 及更高版本獲得 大約 1 年的補丁支援。Kubernetes 1.18 及更早版本獲得大約 9 個月的補丁支援。

根據嚴重程度和可行性，適用的修復程式（包括安全修復程式）可能會被回溯到這三個釋出分支。補丁版本會按照 固定節奏 從這些分支中釋出，並在需要時釋出額外的緊急版本。

釋出經理 組擁有此決定權。

有關更多資訊，請參閱 Kubernetes 補丁釋出 頁面。

支援的版本偏差

kube-apiserver

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

示例

• 最新的 kube-apiserver 版本為 1.34
• 其他 kube-apiserver 例項支援的版本為 1.34 和 1.33

kubelet

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

示例

• kube-apiserver 版本為 1.34
• kubelet 支援的版本為 1.34, 1.33, 1.32 和 1.31

示例

• kube-apiserver 例項的版本為 1.34 和 1.33
• kubelet 支援的版本為 1.33, 1.32 和 1.31（不支援 1.34，因為這將比版本 1.33 的 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.34
• kube-proxy 支援的版本為 1.34, 1.33, 1.32 和 1.31

示例

• kube-apiserver 例項的版本為 1.34 和 1.33
• kube-proxy 支援的版本為 1.33, 1.32 和 1.31（不支援 1.34，因為這將比版本 1.33 的 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.34
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支援的版本為 1.34 和 1.33

示例

• kube-apiserver 例項的版本為 1.34 和 1.33
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 與可以路由到任何 kube-apiserver 例項的負載均衡器通訊
• kube-controller-manager、kube-scheduler 和 cloud-controller-manager 支援的版本為 1.33（不支援 1.34，因為這將比版本 1.33 的 kube-apiserver 例項新）

kubectl

kubectl 支援的版本與 kube-apiserver 相差一個次版本（舊或新）。

示例

• kube-apiserver 版本為 1.34
• kubectl 支援的版本為 1.35, 1.34 和 1.33

示例

• kube-apiserver 例項的版本為 1.34 和 1.33
• kubectl 支援的版本為 1.34 和 1.33（其他版本將與其中一個 kube-apiserver 元件相差一個以上的次版本）

支援的元件升級順序

元件之間支援的版本偏差對元件必須升級的順序有影響。本節描述了將現有叢集從版本 1.33 升級到版本 1.34 時必須升級元件的順序。

（可選）在準備升級時，Kubernetes 專案建議您執行以下操作，以便在升級過程中從儘可能多的迴歸和錯誤修復中受益

• 確保元件位於當前次版本的最新補丁版本。
• 將元件升級到目標次版本的最新補丁版本。

例如，如果您正在執行版本 1.33，請確保您位於最新的補丁版本。然後，升級到 1.34 的最新補丁版本。

kube-apiserver

先決條件

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

將 kube-apiserver 升級到 1.34

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

先決條件

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

將 kube-controller-manager、kube-scheduler 和 cloud-controller-manager 升級到 1.34。kube-controller-manager、kube-scheduler 和 cloud-controller-manager 之間沒有強制的升級順序。您可以按任何順序升級這些元件，甚至可以同時升級。

kubelet

先決條件

• kubelet 通訊的 kube-apiserver 例項的版本為 1.34

（可選）將 kubelet 例項升級到 1.34（或它們可以保留在 1.33、1.32 或 1.31）

kube-proxy

先決條件

• kube-proxy 通訊的 kube-apiserver 例項的版本為 1.34

（可選）將 kube-proxy 例項升級到 1.34（或它們可以保留在 1.33、1.32 或 1.31）