升級版本規則

瞭解目前版本和目標版本對叢集升級的影響，有助於在開始前確認版本偏斜、升級順序和 OS 需求。

版本專屬升級資訊

下表說明各版本的升級資訊。表格下方則列出特定版本的詳細資料。版本會由新到舊排序。找出要升級「至」的版本，查看適用於叢集的具體詳細資料和規則。

版本 先升級 控制層 (CP) 版本 worker 節點集區版本 進階叢集狀態 舊版功能支援 預設和必要的 OS 映像檔 Kubeception 節點升級行為 cert-manager 組合
1.36 管理員叢集 1.36、1.35、1.34 1.36、1.35、1.34 必填 無 ubuntu_cgv2、cos_cgv2 不支援 隨附
1.35 管理員叢集 1.35、1.34、1.33 1.35、1.34、1.33 必填 無 ubuntu_cgv2、cos_cgv2 為必要項目 (cgroup v1 已停用) 不支援 隨附
1.34 管理員叢集 1.34、1.33、1.32 1.34、1.33、1.32 強制 (無法選擇不採用；非進階廣告活動會自動轉換) 無 ubuntu_cgv2 (預設)、cos_cgv2、ubuntu_containerd、cos 不支援 隨附
1.33 管理員叢集 1.33、1.32、1.31 1.33、1.32、1.31 預設 (自動轉換) (僅限 1.32 至 1.33 版可選擇不採用) 無 ubuntu_cgv2 (預設)、cos_cgv2、ubuntu_containerd、cos 不支援 進階叢集套裝組合
1.32 管理員叢集 1.32、1.31、1.30 1.32、1.31、1.30 正式發布版 (支援升級；支援個別和略過節點升級) 無 ubuntu_cgv2 (預設)、cos_cgv2、ubuntu_containerd、cos 不支援 (必須遷移至 Controlplane V2) 進階叢集套裝組合
1.31 管理員叢集 1.31、1.30、1.29 1.31、1.30、1.29 預先發布版 (不升級至 1.32；不執行個別或略過節點升級作業) 是 (Seesaw、F5、Kubeception、非高可用性)；強烈建議遷移至建議功能；必須使用 Dataplane V2 ubuntu_cgv2 (預設)、cos_cgv2、ubuntu_containerd、cos 管理員節點與管理員叢集一起升級；使用者控制層節點與使用者叢集一起升級 未綁定
1.30 使用者叢集 1.30 1.30、1.29、1.28 無法使用 是 (Seesaw、F5、Kubeception、非高可用性)；強烈建議遷移至建議功能 ubuntu_cgv2 (預設)、cos_cgv2、ubuntu_containerd、cos 升級管理員叢集時，CP 和管理員節點也會升級 未綁定
1.29 使用者叢集 1.29、1.30 1.29、1.28、1.16 無法使用 是 (Seesaw、F5、Kubeception、非高可用性) ubuntu_cgv2 (預設)、cos_cgv2、ubuntu_containerd、cos 升級管理員叢集時，CP 和管理員節點也會升級 未綁定
1.28 使用者叢集 1.28、1.29、1.30 1.28、1.16、1.15 無法使用 是 (Seesaw、F5、Kubeception、非高可用性) ubuntu_containerd (預設)、cos、ubuntu_cgv2、cos_cgv2 升級管理員叢集時，CP 和管理員節點也會升級 未綁定

無論是哪個版本，您都必須同時升級負載平衡器節點集區版本 (具有 enableLoadBalancer: true 的節點集區)，並升級至與使用者叢集控制層相同的版本。

各發布版本的升級資訊

找到要升級「至」的版本對應段落，查看升級至該版本所需的具體資訊。

1.36 版本

先升級：管理員叢集

版本偏誤規則：

  • 1.36 版的管理員叢集可以管理 1.36、1.35 和 1.34 版的使用者叢集。
  • 使用者叢集控制層版本：1.36、1.35 或 1.34。
  • worker 節點集區版本：1.36、1.35 或 1.34。

進階叢集狀態：必須使用進階叢集。

略過節點升級：支援。

是否支援舊版功能：否。會阻擋升級。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2。新設定的預設 osImageType 為 ubuntu_cgv2。

Kubeception 節點升級行為：不支援。封鎖升級。

升級工具：

  • gkectl：管理員叢集的必要項目。支援的版本為 1.36、1.37 和 1.38。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援此功能。
  • Google Cloud 控制台：支援使用者叢集升級。
  • Google Cloud CLI：支援使用者叢集升級。

其他規定：

  • 您可以使用 gkectl upgrade admin --async，以非同步方式執行管理員叢集升級作業。

1.35 版

先升級：管理員叢集

版本偏誤規則：

  • 1.35 版的管理員叢集可以管理 1.35、1.34 和 1.33 版的使用者叢集。
  • 使用者叢集控制層版本：1.35、1.34 或 1.33。
  • worker 節點集區版本：1.35、1.34 或 1.33。

進階叢集狀態：必須使用進階叢集。

略過節點升級：支援。

是否支援舊版功能：否。會阻擋升級。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2 為必要 (cgroup v1 已停用)。新設定的預設 osImageType 為 ubuntu_cgv2。您必須先將叢集遷移至 cgroup v2，才能升級。

Kubeception 節點升級行為：不支援。封鎖升級。

升級工具：

  • gkectl：管理員叢集的必要項目。支援的版本為 1.35、1.36 和 1.37。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援此功能。
  • 控制台：支援使用者叢集升級。
  • gcloud CLI：支援使用者叢集升級。

其他規定：

  • 您可以使用 gkectl upgrade admin --async，以非同步方式執行管理員叢集升級作業。

1.34 版

先升級：管理員叢集

版本偏誤規則：

  • 1.34 版的管理員叢集可以管理 1.34、1.33 和 1.32 版的使用者叢集。
  • 使用者叢集控制層版本：1.34、1.33 或 1.32。

  • worker 節點集區版本：1.34、1.33 或 1.32。

進階叢集狀態：必須使用進階叢集。

略過節點升級：支援。

是否支援舊版功能：否。會阻擋升級。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。預設 osImageType 為 ubuntu_cgv2。

Kubeception 節點升級行為：不支援。封鎖升級。

升級工具：

  • gkectl：管理員叢集的必要項目。將非進階叢集轉換為進階叢集時，必須使用這個指令 (1.34 版起強制使用；gkectl 二進位檔版本必須與目標發布版本完全一致)。支援的版本為 1.34、1.35 和 1.36。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援此功能。
  • 控制台：支援進階使用者叢集升級。
  • gcloud CLI：支援進階使用者叢集升級。

其他規定：

升級至 1.34 版時，須遵守下列額外規定：

  • 升級至 1.34 版時，非進階叢集會自動轉換為進階叢集。如要瞭解從非進階叢集升級至進階叢集的特定規則，請參閱「將叢集更新或升級至進階叢集」。

  • 隨附的 cert-manager 為必要項目，且已更新至 1.19 版，會覆寫現有的自訂 cert-manager 安裝項目。如要進一步瞭解隨附 cert-manager 的升級授權，請參閱「使用隨附的 cert-manager」。

  • 節點容器執行階段已升級至 containerd 2.0。這可能會有下列影響：

    • containerd 2.0 不支援舊版 Docker 映像檔資訊清單 v2 或結構定義 1 映像檔。升級至 1.34 版前，請確認工作負載使用 Docker 結構定義 2 或符合 OCI 標準的格式提取容器映像檔。
    • 在 containerd 2.0 中，儲存庫鏡像設定會遷移至 hosts.toml 格式。如果您直接在節點上管理自訂鏡像設定或實體隔離的登錄檔端點，請確認設定與 hosts.toml 一致。
    • 如果您使用自訂 DaemonSet 或指令碼修補 /etc/containerd/config.toml，請確認這些項目未使用已淘汰的 containerd v1 設定選項，否則 containerd 2.0 可能無法啟動 containerd。

  • nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate 欄位的預設值在 1.34.300 版中有所變更。如要在 1.34.300 以上版本中依序升級節點集區，請在使用者叢集設定檔中設定 nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate: 1：

    • 在 1.34.0-1.34.200 版中，nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate 預設為 1，會依序更新節點集區，一次一個。
    • 如果是 1.34.300 以上版本，nodePoolUpdatePolicy.maximumConcurrentNodePoolUpdate 預設為 0，會同時更新所有節點集區。

    詳情請參閱「設定節點集區更新政策」。

  • 升級預檢會主動驗證叢集中的所有 PodDisruptionBudget (PDB) 設定。升級前，請確認工作負載沒有過度限制的 PDB (例如 maxUnavailable: 0 或 minAvailable 符合副本總數)，以免節點耗盡或預檢失敗。

  • 如果升級作業中斷，請直接升級至 1.34.300-gke.59 以上版本。如果您需要在失敗後重新執行 gkectl upgrade admin，這個版本可防止啟動叢集遭到刪除。詳情請參閱「重新執行 gkectl upgrade admin 會刪除 bootstrap 叢集」。

  • 除了從非進階叢集轉換為進階叢集的情況外，您可以使用 gkectl upgrade admin --async 非同步執行進階叢集的管理員叢集升級作業。

1.33 版

先升級：管理員叢集

版本偏誤規則：

  • 1.33 版的管理員叢集可以管理 1.33、1.32 和 1.31 版的使用者叢集。
  • 使用者叢集控制層版本：1.33、1.32 或 1.31。

  • worker 節點集區版本：1.33、1.32 或 1.31。

進階叢集狀態：進階叢集是預設叢集類型，會自動轉換。允許選擇不採用。詳情請參閱「升級及維護非進階叢集」。如果將 enableAdvancedCluster 設為 false，就無法建立新叢集。

略過節點升級：支援。

是否支援舊版功能：否。會阻擋升級。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。預設 osImageType 為 ubuntu_cgv2。

Kubeception 節點升級行為：不支援。封鎖升級。

升級工具：

  • gkectl：將非進階叢集轉換為進階叢集時，必須使用這個引數 (gkectl 二進位檔版本必須與目標發布版本完全相符)。管理員叢集必須提供這項資訊。支援的版本為 1.33、1.34 和 1.35。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援此功能。
  • 控制台：支援進階使用者叢集升級。
  • gcloud CLI：支援進階使用者叢集升級。

其他規定：

升級至 1.33 版時，須符合下列額外規定：

  • 從 1.32 升級至 1.33 時，系統預設會自動將非進階叢集轉換為進階叢集。您可以保留非進階叢集。如要進一步瞭解如何讓叢集維持非進階狀態，請參閱「升級及維護非進階叢集」。

  • 進階叢集會自動安裝並綁定 cert-manager 1.18 版，覆寫現有的自訂 cert-manager 安裝項目。如要進一步瞭解隨附 cert-manager 的升級授權，請參閱「使用隨附的 cert-manager」。

  • 如果您在這個版本中升級至進階叢集，則從非進階叢集轉換為進階叢集時，gkectl 二進位檔版本必須與目標版本完全相符。這項規定僅適用於升級至進階叢集時。對於進階叢集的所有其他升級，則適用標準版本偏誤規則。

  • 如果升級作業中斷，請直接升級至 1.33.700-gke.71 以上版本。如果您需要在失敗後重新執行 gkectl upgrade admin，這個版本可防止啟動叢集遭到刪除。

  • 如果所有使用者叢集都執行 Controlplane V2，您可以使用 gkectl upgrade admin --async，以非同步方式升級進階叢集和非進階高可用性叢集的管理員叢集。從非進階叢集轉換為進階叢集時，無法使用 --async 旗標。

1.32 版

先升級：管理員叢集

版本偏誤規則：

  • 1.32 版的管理員叢集可以管理 1.32、1.31 和 1.30 版的使用者叢集。
  • 使用者叢集控制層版本：1.32、1.31 或 1.30。

  • worker 節點集區版本：1.32、1.31 或 1.30。

進階叢集狀態：支援。

略過節點升級：支援。

是否支援舊版功能：否。會阻擋升級。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。預設 osImageType 為 ubuntu_cgv2。

Kubeception 節點升級行為：不支援。封鎖升級。必須遷移至 Controlplane V2。

升級工具：

  • gkectl：將非進階叢集轉換為進階叢集時，必須使用這個引數 (gkectl 二進位檔版本必須與目標發布版本完全相符)。管理員叢集必須提供這項資訊。支援的版本為 1.32、1.33 和 1.34。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援此功能。
  • 控制台：支援進階使用者叢集升級。
  • gcloud CLI：支援進階使用者叢集升級。

其他規定：

升級至 1.32 版時，須符合下列額外規定：

  • 這是第一個可選用升級至完全支援的GA進階叢集的版本。您可以選擇：

    • 升級至非進階叢集，並維護非進階叢集。如果選擇這個選項，從這個版本開始，您可以執行下列操作：

      • 分別升級使用者叢集的控制層和 worker 節點集區。worker 節點集區最多可比控制層落後 2 個子版本。
      • 以非同步方式升級管理員和使用者叢集。

    • 升級至非進階叢集，然後將非進階叢集轉換為進階叢集。如果選擇這個選項，從這個版本開始，您可以執行下列操作：

      • 升級非進階叢集時，請分別升級使用者叢集的控制層和 worker 節點集區，但轉換為進階叢集時則不必這麼做。worker 節點集區最多可比控制層落後 2 個子版本。
      • 升級非進階叢集時，請以非同步方式升級管理員和使用者叢集。
      • 轉換為進階叢集時，請升級至 1.32.1000-gke.57 以上版本，因為這個版本已修正已知問題，可避免刪除啟動叢集。

    • 直接升級至進階叢集。如果選擇這個選項，從這個版本開始，系統會套用下列設定：

      • 您必須一併升級控制層和所有節點集區。
      • 您可以對使用者叢集執行非同步升級，但無法對管理員叢集執行。
      • 請升級至發布版本 1.32.1000-gke.57 以上版本，因為這些版本已修正已知問題，可避免啟動叢集無法刪除。

  • 從這個版本開始，系統不再支援下列舊版功能。詳情請參閱「舊版功能」：

    • Dataplane V1 (Calico)。請先升級至 Dataplane V2，再升級至 1.32。
    • Seesaw。請先升級至替代負載平衡器，再升級至 1.32。
    • 整合式 F5 BIG-IP。請先升級至替代負載平衡器，再升級至 1.32。
    • Kubeception。請先升級至非 Kubeception 叢集，再升級至 1.32。
    • 非高可用性管理員叢集。升級至 1.32 前，請先升級至高可用性管理員叢集。

  • 從非進階叢集轉換為進階叢集時，gkectl 二進位檔版本必須與目標發布版本完全相符。這項規定僅適用於升級至進階叢集時。對於進階叢集的所有其他升級，則適用標準版本偏誤規則。

  • 如果升級作業中斷，請直接升級至 1.32.1000-gke.57 以上版本。如果您需要在失敗後重新執行 gkectl upgrade admin，這個版本可防止啟動叢集遭到刪除。

  • 在 1.32 以上版本中，如果所有使用者叢集都執行 Controlplane V2，您可以使用 gkectl upgrade admin --async，以非同步方式升級進階叢集和非進階 HA 叢集的管理員叢集。從非進階叢集轉換為進階叢集時，無法使用 --async 旗標。

1.31 版本

先升級：管理員叢集

版本偏誤規則：

  • 1.31 版的管理員叢集可以管理 1.31、1.30 和 1.29 版的使用者叢集。
  • 使用者叢集控制層版本：1.31、1.30 或 1.29。
  • worker 節點集區版本：1.31、1.30 或 1.29。(1.31 進階叢集不支援)。
  • 如要從 1.29/1.30 升級至 1.31，您必須先將所有叢集升級至 1.30 版，再將管理員叢集升級至 1.31。

進階叢集狀態：僅供預覽。無法升級至更高版本。

略過節點升級：支援。

支援的舊版功能：必須使用 Dataplane V2；仍支援 Kubeception、Seesaw 和 F5。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。預設 osImageType 為 ubuntu_cgv2。

Kubeception 節點升級行為：管理員節點會與管理員叢集一起升級；使用者控制層節點會與使用者叢集一起升級。

升級工具：

  • gkectl：管理員叢集、非進階叢集和進階叢集 (預先發布版，適用於這個版本) 必須提供。支援的版本為 1.31、1.32 和 1.33。
  • Terraform：如果使用者叢集是以 Terraform 建立，則支援已註冊的使用者叢集。
  • 控制台：支援已註冊的使用者叢集升級。
  • gcloud CLI：支援已註冊的使用者叢集升級。

其他規定：

升級至 1.31 版時，須遵守下列額外規定：

  • 這個版本推出預先發布版進階叢集。在這個版本中，您無法將非進階叢集遷移至進階叢集。您可以建立新的進階叢集，但無法將這些預先發布版進階叢集升級至更高版本。不建議在這個版本中建立進階叢集。如要進一步瞭解產品推出階段 (例如預先發布版)，請參閱「產品推出階段」。

  • 在 1.31 以上版本中，升級架構已變更為管理員叢集必須高於或等於使用者叢集的模式。過去，使用者叢集最多可以比管理員叢集高兩個子版本。

  • 您必須先升級管理員叢集，才能升級由管理員叢集管理的使用者叢集。管理員叢集可以管理子版本相同或最多低 2 個子版本的使用者叢集。舉例來說，1.31 版的管理員叢集可以管理 1.31、1.30 和 1.29 版的使用者叢集。

  • 如要從 1.29 升級至 1.31，必須先將 1.30 套件設為中繼步驟。您必須在管理員工作站下載 1.30 和 1.31 套件，才能升級至 1.31。如要執行從 1.29 到 1.31 的略過版本升級，請按照下列步驟操作：

    1. 僅將使用者叢集控制層從 1.29 升級至 1.30 (worker 節點集區維持在 1.29)。
    2. 將管理員叢集從 1.29 升級至 1.30。
    3. 將管理員叢集從 1.30 升級至目標 1.31。
    4. 將使用者叢集控制層和 worker 節點集區一併升級至 1.31。

  • 如果您使用 Kubeception，管理員叢集節點會在管理員叢集升級期間升級，使用者叢集控制層節點則會在使用者叢集升級期間升級。

  • 如要升級至 1.31，必須啟用 Dataplane V2。為避免 CNI 遷移期間發生網路政策衝突和流量下降，您必須手動儲存並刪除所有 NetworkPolicy 物件，並在升級後還原這些物件。如要改用 Dataplane V2，請執行下列操作：

    1. 匯出並儲存所有自訂網路政策：

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy -A -o wide \
    --field-selector metadata.namespace!=kube-system
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    get networkpolicy POLICY_NAME \
    -n NAMESPACE -o yaml > policy.yaml

      更改下列內容：

      • USER_CLUSTER_KUBECONFIG：使用者叢集的 kubeconfig 檔案路徑
      • POLICY_NAME：NetworkPolicy 物件的名稱
      • NAMESPACE：NetworkPolicy 物件的命名空間

    2. 從叢集刪除網路政策：

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    delete networkpolicy POLICY_NAME \
    -n NAMESPACE

    3. 在使用者叢集設定檔中設定 enableDataplaneV2: true，然後升級至 1.31。

    4. 1.31 升級作業完成後，請套用已儲存的政策，讓 Cilium 將政策完整編譯為擴充 Berkeley 封包篩選器 (eBPF)：

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
    apply -f policy.yaml

  • 如果您有高可用性管理員叢集，且所有使用者叢集都執行 Controlplane V2，則可使用 gkectl upgrade admin --async 指令以非同步方式執行升級。

  • 所有使用者叢集都必須啟用 Dataplane V2。將使用者叢集升級至 1.31 版之前，請按照「啟用 Dataplane V2」中的步驟操作。

  • 1.32 版不支援舊版功能，您可以在 1.30 和 1.31 版中替換這些功能，以免升級至 1.32 版時發生問題。

1.30 版

先升級：使用者叢集

版本偏誤規則：

  • 1.30 版的使用者叢集可由 1.30、1.29 或 1.28 版的管理員叢集管理。
  • 1.30 版的管理員叢集只能管理 1.30 版的使用者叢集。所有使用者叢集和管理員叢集都必須達到 1.30，才能將管理員叢集升級至 1.31，而且必須先將管理員叢集升級至 1.31，才能將任何使用者叢集升級至 1.31。
  • 使用者叢集控制層版本：1.30。
  • worker 節點集區版本：1.30、1.29 或 1.28。

進階叢集狀態：不適用。

略過節點升級：支援。

支援舊版功能：支援。強烈建議您改用建議功能。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。預設 osImageType 為 ubuntu_cgv2。

  • Kubeception 節點升級行為：** 升級管理員叢集時，控制層和管理員節點會一併升級

升級工具：

  • gkectl：管理員叢集的必要項目。支援的版本為 1.30、1.31 和 1.32。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援已註冊的使用者叢集。
  • 控制台：支援已註冊的使用者叢集升級。
  • gcloud CLI：支援已註冊的使用者叢集升級。

其他規定：

升級至 1.30 版時，須符合下列額外規定：

  • 對於這個版本和所有先前版本，您必須先遷移所有使用者叢集，才能升級管理員叢集。管理員叢集的子版本必須與任何代管使用者叢集相同或更低。

  • 如果您使用 Kubeception，升級期間會發生下列情況：

    1. 升級使用者叢集。由於使用者控制層位於管理員叢集內，因此執行 gkectl upgrade cluster 只會升級 worker 節點集區。
    2. 升級管理員叢集。管理員叢集升級作業會升級管理員節點，並同時自動升級所有使用者叢集控制層。

  • 如果您使用 Controlplane V2，升級期間會發生下列情況：

    1. 升級使用者叢集。這會升級控制層和 worker 節點集區。
    2. 升級管理員叢集。管理員節點會隨之升級。

  • 建立新的使用者叢集時，您必須將 enableControlplaneV2 欄位設為 true，這是這個版本開始的預設值。如果將 enableControlplaneV2 欄位設為 false，gkectl 會拒絕檔案，且不會建立叢集。

  • 如果您有高可用性管理員叢集，且所有使用者叢集都執行 Controlplane V2，則可使用 gkectl upgrade admin --async 指令以非同步方式執行升級。

  • 1.32 版不支援舊版功能，您可以在 1.30 和 1.31 版中替換這些功能，以免升級至 1.32 版時發生問題。

1.29 版

先升級：使用者叢集

版本偏誤規則：

  • 1.29 版的使用者叢集可由 1.29、1.28 或 1.16 版的管理員叢集管理。
  • 1.29 版的管理員叢集可以管理 1.29 和 1.30 版的使用者叢集。1.29 版的管理員叢集無法管理 1.31 版的使用者叢集，因為所有叢集都必須先升級至 1.30 版，且管理員叢集必須先升級至 1.31 版，使用者叢集才能升級至 1.31 版。
  • 使用者叢集控制層版本：1.29 或 1.30，最多高 1 個子版本。
  • worker 節點集區版本：1.29、1.28 或 1.16。

進階叢集狀態：不適用。

略過節點升級：支援。

支援舊版功能：支援。

預設和必要的 OS 映像檔：ubuntu_cgv2、cos_cgv2、ubuntu_containerd、cos。預設 osImageType 為 ubuntu_cgv2。

Kubeception 節點升級行為：控制層和管理員節點會在管理員叢集升級期間升級

升級工具：

  • gkectl：管理員叢集的必要項目。支援的版本為 1.29、1.30 和 1.31。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援已註冊的使用者叢集。
  • 控制台：支援已註冊的使用者叢集升級。
  • gcloud CLI：支援已註冊的使用者叢集升級。

其他規定：

升級至 1.29 版時，須遵守下列額外規定：

  • worker 節點最多可比控制層落後 2 個子版本 (n+2)。
  • 升級 worker 節點集區時，可以略過子版本。例如，您可以將 worker 節點集區從 1.28 升級至 1.30。
  • 預檢作業會以 Pod 的形式，在管理員叢集或臨時啟動 kind 叢集內執行，而非在管理員工作站上執行。
  • 從這個版本開始，您可以使用 gkectl upgrade cluster --dry-run 執行預檢，不必升級叢集。
  • 如果您有高可用性管理員叢集，且所有使用者叢集都執行 Controlplane V2，則可使用 gkectl upgrade admin --async 指令以非同步方式執行升級。

1.28 版本

先升級：使用者叢集

版本偏誤規則：

  • 1.28 版的使用者叢集可由 1.28、1.16 或 1.15 版的管理員叢集管理。
  • 1.28 版的管理員叢集可以管理 1.28、1.29 和 1.30 版的使用者叢集。
  • 使用者叢集控制層版本：1.28、1.29 或 1.30，最多可高出 2 個子版本。
  • worker 節點集區版本：1.28、1.16 或 1.15，最多可低 2 個子版本。

進階叢集狀態：不適用。

略過節點升級：支援。

支援舊版功能：支援。

預設和必要的 OS 映像檔：ubuntu_containerd、cos、ubuntu_cgv2、cos_cgv2。預設 osImageType 為 ubuntu_containerd。

Kubeception 節點升級行為：控制層和管理員節點會在管理員叢集升級期間升級

升級工具：

  • gkectl：管理員叢集的必要項目。支援的版本為 1.28、1.29 和 1.30。
  • Terraform：如果您使用 Terraform 建立使用者叢集，則支援已註冊的使用者叢集。
  • 控制台：支援已註冊的使用者叢集升級。
  • gcloud CLI：支援已註冊的使用者叢集升級。

其他規定：

升級至 1.28 版時，須遵守下列額外規定：

  • 您必須啟用 kubernetesmetadata.googleapis.com，並將 roles/kubernetesmetadata.publisher 授予記錄/監控服務帳戶。否則預檢可能會失敗，或出現 403 PERMISSION_DENIED 錯誤。啟用 API，並將角色授予現有的 logging-monitoring 服務帳戶：

    gcloud services enable kubernetesmetadata.googleapis.com
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:LOGGING_SA" \
    --role="roles/kubernetesmetadata.publisher"

    更改下列內容：

    • PROJECT_ID：使用者叢集所屬機群主機專案的 ID。
    • LOGGING_SA：記錄/監控服務帳戶的電子郵件地址。

  • 雖然在技術上，您可以在節點集區升級期間略過版本，但這項功能是做為預先發布版功能推出，不建議用於這個版本。如要進一步瞭解產品推出階段 (例如預先發布版)，請參閱「產品推出階段」。

  • 如果節點集區含有隨附的負載平衡器，則必須與叢集版本完全比對。

  • 您可以設定 nodePools[i].updateStrategy.rollingUpdate.maxSurge 欄位，同時升級多個節點。vSphere 叢集必須有足夠的 CPU、RAM 和可用 IP 位址，才能在升級期間容納額外的增加 VM：

    • 設為 maxSurge: 1 (預設) 可一次升級一個節點 (依序執行排除、替換、驗證，然後重複)。
    • 設定 maxSurge: N (其中 N > 1)，最多可同時佈建及耗盡 N 個 worker 節點 (例如，maxSurge: 3 會同時升級 3 個 worker 節點)。

  • 管理員工作站必須至少有 100 GB 的可用磁碟空間，才能升級管理員工作站。

  • 用於升級的 gkectl 版本最多可比目前叢集高兩個子版本。無法使用較低的子版本。

1.28 之前的版本

如要升級至 1.28 版之前的版本，請遵循下列額外規定。1.16 至 1.28 之間沒有發布版本：

1.16 版：

  • 管理員和使用者叢集之間，以及控制層和節點集區之間的版本差異，只能相差 1 個子版本。舉例來說，1.15 版的管理員叢集只能管理 1.15 或 1.16 版的使用者叢集。使用者叢集控制層升級至 1.16 後，可管理執行 1.15 或 1.16 版的 worker 節點集區。1.14 版的集區必須先升級至 1.15 版，控制層才能升級至 1.16 版。如要進一步瞭解版本偏差，請參閱「版本偏差規則」。
  • 建立叢集或將叢集升級至 1.16 版時，叢集會自動註冊至 GKE On-Prem API。這項異動可讓您透過控制台、gcloud CLI 和 Terraform 查看、監控及升級使用者叢集，不必再只使用管理員工作站殼層。

1.14 版：

  • 您可以先只升級使用者叢集控制層，這樣就不必同時清空及升級每個 worker 節點集區。
  • 升級期間，系統會自動檢查及更新工作站上現有的管理員和使用者叢集 kubeconfig 檔案，並自動更新憑證。

1.13 版：

  • 在這個版本之前，您可以建立離線管理員叢集。這個版本需要您將管理員叢集註冊至 Google Cloud。如要瞭解如何註冊叢集，請參閱「註冊現有叢集」。
  • 如要將叢集升級至 Google Distributed Cloud 軟體 (僅限 VMware 1.13 以上版本)，您必須先將仍使用 Docker Engine 的使用者叢集節點集區更新為 containerd。

使用套裝組合 cert-manager

您必須使用隨附的 cert-manager，該工具會自動安裝在進階叢集上。從非進階叢集遷移至進階叢集時，整合式 cert-manager 會自動覆寫任何客戶安裝的 cert-manager 版本。在更新或升級至進階叢集之前，請確認現有的 cert-manager 未套用重要的自訂設定或功能。

如要查看是否已將重要的自訂設定或功能套用至 cert-manager，請按照下列步驟操作：

  • 暫停持續部署工具。如果您使用 GitOps 工具 (例如 Config Sync、ArgoCD 或 Flux) 管理 cert-manager，請先暫停同步處理，或從存放區中移除 cert-manager 資訊清單，再進行升級。如果 GitOps 控制器在叢集升級期間嘗試將 cert-manager 協調回舊版本或自訂資訊清單，就會建立協調迴圈，可能導致叢集升級停滯。
  • 升級前，請勿手動解除安裝或刪除 cert-manager Pod、命名空間或 CRD。gkectl 會就地管理這些升級作業。
  • 如果您修改了 cert-manager 部署作業旗標、節點選取器或 Pod 資源限制，請將其還原。進階叢集不支援自訂二進位引數，或 cert-manager 的部署層級覆寫。
  • 如果您使用專門的外部簽發者、私人 ACME DNS-01 Webhook 外掛程式或自訂 Webhook，請確認第三方外掛程式與要升級版本的隨附 cert-manager 版本相容。

詳情請參閱「升級至與進階叢集搭配使用的 cert-manager」。

下表列出哪些發布版本需要隨附 cert-manager：

版本 新叢集的狀態 現有叢集升級狀態 是否需要隨附 cert-manager？
1.34+ 必填 強制轉換 (隨附 v1.19) 所有客戶都必須提供。非進階叢集已不復存在。
1.33 標準/所有新叢集的預設值 預設會自動轉換為進階叢集 (隨附 v1.18) 幾乎所有叢集都必須啟用這項功能，除非明確使用 enableAdvancedCluster: false 選擇不啟用 (僅限 1.32 → 1.33)。
1.32 (正式發布版) 預設為啟用 可選擇轉換為進階叢集 如果已啟用進階叢集，則為必填欄位。
1.31 (預先發布版) 選用 (enableAdvancedCluster: true) 不支援 如果已啟用進階叢集，則為必填欄位。

如要查看每個支援版本隨附的 cert-manager 版本，請參閱「隨附的 cert-manager 版本」。

Controlplane V2

啟用 Controlplane V2 後，使用者叢集的控制層會在使用者叢集上執行。如果是 Controlplane V2，使用者叢集控制層節點會在使用者叢集升級期間升級，管理員叢集控制層節點則會在管理員叢集升級期間升級。

舊版功能

下表列出 1.32 以上版本封鎖的舊版功能。如果您使用這些功能，必須先遷移至建議的替代方案，才能升級至 1.32 以上版本。

| 舊版功能 (1.32 版起禁止使用) | 建議替代方案 | 遷移操作說明連結 | | --- | --- | --- | | Dataplane V1 (Calico) | Dataplane V2 (Cilium/eBPF) | 遷移至 Dataplane V2| | Kubeception | Controlplane V2 | 遷移至 Controlplane V2 | | 非高可用性管理員叢集 (1 個副本) | 高可用性管理員叢集 (3 個副本) | 遷移至高可用性管理員叢集 | | Seesaw 負載平衡器 | MetalLB 或 ManualLB | 遷移至 MetalLB 或遷移負載平衡器類型| | 整合式 F5 BIG-IP (loadBalancer.kind: "F5BigIP") | ManualLB (與 F5 Big-IP Controller 或 CCGI 搭配) | 遷移至 ManualLB |

如要瞭解如何從舊版功能遷移至建議功能，請參閱「規劃叢集遷移至建議功能」。

Kubeception 遷移和版本行為

Kubeception 是舊版功能，必須先遷移至 Controlplane V2，才能升級至 1.32 以上版本。

對於採用 Kubeception 的叢集，升級行為會因版本而異：

  • 1.28：在管理員叢集升級期間，升級控制層和管理員節點
  • 1.29 版：在管理員叢集升級期間，升級控制層和管理員節點

  • 1.30 版：控制層和管理員節點會在管理員叢集升級期間升級。如果您使用 Kubeception，升級期間會發生下列情況：

    1. 升級使用者叢集。由於使用者控制層位於管理員叢集內，因此執行 gkectl upgrade cluster 只會升級 worker 節點集區。
    2. 升級管理員叢集。管理員叢集升級作業會升級管理員節點，並同時自動升級所有使用者叢集控制層。

  • 1.31 版：管理員節點會與管理員叢集一起升級；使用者控制層節點會與使用者叢集一起升級。

  • 1.32 以上版本：不支援 Kubeception。您必須先遷移至 Controlplane V2，才能升級至 1.32 以上版本。

    如要進一步瞭解如何將 Kubeception 遷移至 Controlplane V2，請參閱「規劃叢集遷移作業，改用建議功能」。

版本偏差與升級時略過版本

版本偏誤是指管理員叢集與其代管使用者叢集之間，或使用者叢集控制層與使用者叢集節點集區之間，允許的子版本差異。

版本偏誤與升級時略過子版本不同。

只有在升級控制層後，升級 worker 節點集區時，才能略過子版本。這項規定適用於進階和非進階叢集，但執行 1.31 版和 1.28 版之前的進階叢集除外。舉例來說，如果 worker 節點集區的版本為 1.29，請先將使用者叢集控制層更新至 1.30，再更新至 1.31。控制層升級至 1.31 後，請直接將 worker 節點集區從 1.29 升級至 1.31，不必升級至 1.30。詳情請參閱「升級節點集區時略過版本」。

如要升級至高於下一個次要版本的版本，請先升級至下一個次要版本，再升級至更高的次要版本。升級管理員和使用者叢集控制層時，無法略過子版本。舉例來說，如果您想從 1.34.x 版升級至 1.36.x 版，則無法直接升級。您必須先從 1.34.x 升級至 1.35.x，再升級至 1.36.x。

使用者叢集的控制層最多可比叢集中的 worker 節點集區高 2 個子版本。舉例來說，如果使用者叢集的控制層版本為 1.36，叢集中的 worker 節點集區版本可以是 1.34、1.35 或 1.36。

允許哪些版本偏差？

管理員叢集最多可管理低 2 個子版本的使用者叢集。舉例來說，如果管理員叢集為 1.31 版，則由該管理員叢集管理的使用者叢集可以是 1.29、1.30 或 1.31 版。

1.31 版之前，適用下列版本偏誤規則：

  • 如果是 1.28 至 1.30 版，使用者叢集最多可以比管理員叢集高 2 個子版本。舉例來說，如果管理員叢集為 1.15，則該管理員叢集管理的使用者叢集可以為 1.15、1.16 或 1.28。您必須先將管理員叢集升級至 1.16 以上版本，才能將 1.28 使用者叢集升級至 1.29。1.31 版會變更升級順序，要求先升級管理員叢集，因此 1.29 或 1.30 版的管理員叢集無法管理 1.31 或 1.32 版的使用者叢集。所有使用者叢集和管理員叢集都必須達到 1.30，才能將管理員叢集升級至 1.31。
  • 如果是 1.16 以下版本，使用者叢集只能比管理員叢集高 1 個子版本。舉例來說，如果管理員叢集為 1.15，則由該管理員叢集管理的使用者叢集可以為 1.15 或 1.16。

我是否必須一次升級所有使用者叢集？

升級使用者叢集時，您可以選擇下列其中一項：

  • 同時升級整個使用者叢集，包括控制層和叢集中的所有節點集區。
  • 升級使用者叢集的控制層，並將節點集區保留在目前版本。
  • 升級使用者叢集的控制層，並選擇性升級節點集區。

您採用的方法取決於多項因素，例如：

  • 叢集所在的環境 (正式環境或非正式環境)。
  • 維護期間的長度。
  • 使用者叢集的版本。

舉例來說，您可能想在開發環境中，同時升級使用者叢集的控制層和所有節點集區。不過，在維護期間較短的正式環境中，您可能只想升級控制層，因為這項作業所需時間較短，且控制層升級作業不應中斷使用者工作負載。

負載平衡器節點集區 (具有 enableLoadBalancer: true 的節點集區) 必須與叢集版本相同。

「gkectl」的版本規則

您可以用來升級的 gkectl 版本取決於目標叢集版本 (也就是要升級至的叢集版本)。通常，您會使用與叢集目標版本相同的 gkectl 版本。升級期間會強制執行下列規則：

  • gkectl 版本必須等於或高於目標次要叢集版本。舉例來說，如果您要將 1.29 叢集升級至 1.30，則必須使用 gkectl 1.30 以上版本。修補程式版本則不影響。

  • gkectl 版本最多可比目前的叢集版本高兩個子版本。舉例來說，如要將 1.28 叢集升級至 1.29，請使用 gkectl 1.29 或 1.30 版，但不要使用 1.31 版，因為該版本比叢集版本高三個子版本。

從非進階叢集轉換為進階叢集時，gkectl 二進位檔版本必須與目標發布版本完全一致。這項嚴格的版本規定僅適用於升級至進階叢集時。所有其他進階叢集升級作業，均適用標準版本偏誤規則。

修補程式版本升級規則

請盡可能升級至最新修補程式版本，確保叢集已套用最新安全性修正。修補程式版本不會影響版本偏斜和升級規則。如果是特定子版本，您可以升級至任何更高的修補程式版本。舉例來說，您可以從 1.35.0 升級至 1.35.1，也可以從 1.35.1 升級至 1.35.3。

後續步驟