如果叢集執行 Cloud Service Mesh、Config Sync、Policy Controller 或 Config Controller 等 GKE Enterprise 元件，請查看 GKE Enterprise 版本和升級支援情形，並在升級前後向 Google Distributed Cloud 確認支援的版本。

相容性檢查的依據是 Cloud Service Mesh、Config Sync、Policy Controller 或 Config Controller 部署所在的管理員或使用者叢集。

檢查叢集資源使用率

為確保節點排空時 Pod 可以疏散，且升級叢集有足夠資源可管理升級作業，請檢查叢集的目前資源用量。如要查看叢集的資源用量，請使用 Google Cloud Observability 中的自訂資訊主頁。

您可以使用 kubectl top nodes 等指令取得目前的叢集資源用量，但資訊主頁可提供更詳細的資源用量檢視畫面。這項資源用量資料有助於指出升級時對系統的影響最小，例如週末或晚上，具體取決於執行的工作負載和用途。

管理員叢集升級的時間可能不如使用者叢集重要，因為管理員叢集升級通常不會造成應用程式停機。不過，在開始升級管理員叢集前，請務必檢查是否有可用資源。此外，升級管理員叢集可能會有風險，因此建議在叢集管理存取權較不重要的使用期間進行升級。

管理員叢集控制層資源

所有升級控制器和作業都會在管理叢集控制層節點中執行。檢查這些控制層節點的資源耗用量，瞭解可用的運算資源。升級程序通常需要 1000 millicore 的 CPU (1000 mCPU) 和 2 到 3 GiB 的 RAM，才能處理每組生命週期控制器。請注意，CPU 單位「mCPU」代表「千分之一的核心」，因此每個生命週期控制器集在每個節點上，1000 個毫微核心相當於一個核心。如要減少升級期間所需的額外運算資源，請盡量讓使用者叢集維持相同版本。

在下列範例部署作業中，兩個使用者叢集與管理員叢集版本不同：

管理員叢集	使用者叢集 1	使用者叢集 2
1.13.3	1.13.0	1.13.2

系統會在管理員控制器中，為每個使用的版本部署一組生命週期控制器。在這個範例中，有三組生命週期控制器：1.13.3、1.13.0 和 1.13.2。每組生命週期控制器總共會耗用 1000 mCPU 和 3 GiB RAM。這些生命週期控制器的目前資源總消耗量為 3000 mCPU 和 9 GiB RAM。

如果使用者叢集 2 升級至 1.13.3，現在會有兩組生命週期控制器：1.13.3 和 1.13.0：

管理員叢集	使用者叢集 1	使用者叢集 2
1.13.3	1.13.0	1.13.3

生命週期控制器現在總共會耗用 2000 mCPU 和 6 GiB 的 RAM。

如果使用者叢集 1 升級至 1.13.3，機群現在會以相同版本 (1.13.3) 執行：

管理員叢集	使用者叢集 1	使用者叢集 2
1.13.3	1.13.3	1.13.3

現在只有一組生命週期控制器，總共會耗用 1000 mCPU 和 3 GiB 的 RAM。

在以下範例中，所有使用者叢集都是相同版本。如果升級管理員叢集，系統只會使用兩組生命週期控制器，因此運算資源用量會減少：

管理員叢集	使用者叢集 1	使用者叢集 2
1.14.0	1.13.3	1.13.3

在本例中，生命週期控制器會再次耗用總共 2000 mCPU 和 6 GiB 的 RAM，直到所有使用者叢集都升級至與管理員叢集相同的版本為止。

如果控制平面節點在升級期間沒有額外的運算資源，您可能會看到 Pod (例如 anthos-cluster-operator、capi-controller-manager、cap-controller-manager 或 cap-kubeadm-bootstraper) 處於 Pending 狀態。如要解決這個問題，請將部分使用者叢集升級至相同版本，以整合版本並減少使用的生命週期控制器數量。如果升級作業已停滯，您也可以使用 kubectl edit deployment 編輯待處理的部署作業，降低 CPU 和 RAM 要求，使其符合管理員叢集控制平面。

下表詳細列出不同升級情境的運算資源需求：

叢集	需要管理員叢集資源
升級使用者叢集	升級至其他叢集的相同版本：不適用升級至其他管理員或使用者叢集的不同版本： 1000 mCPU 和 3 GiB RAM 混合叢集中的使用者叢集具有相同的資源需求。
升級管理員叢集 (連同使用者叢集)	1000 mCPU 和 3 GiB RAM
升級混合式叢集 (不含使用者叢集)	1000 mCPU 和 3 GiB RAM 突增。資源會在用完後傳回。
獨立式	200 mCPU 和 1 GiB RAM 突增。資源會在用完後傳回。

備份叢集

開始升級前，請使用 bmctl backup cluster 指令備份叢集。

由於備份檔含有私密資訊，請妥善保管。

確認叢集已正確設定並正常運作

如要在升級前檢查叢集健康狀態，請在叢集上執行 bmctl check cluster。這項指令會執行進階檢查，例如找出設定不正確的節點，或 Pod 處於停滯狀態的節點。

執行 bmctl upgrade cluster 指令升級叢集時，系統會執行一些預檢。如果這些檢查未順利完成，升級程序就會停止。建議您使用 bmctl check cluster 指令主動找出並修正這些問題，而不是依賴前置檢查，因為前置檢查的目的是保護叢集免於任何可能的損壞。

查看使用者工作負載部署作業

使用者工作負載有兩個考量因素：排空和 API 相容性。

工作負載排空

升級期間，節點上的使用者工作負載會排空。如果工作負載只有單一副本，或所有副本都位於相同節點，工作負載排空可能會導致叢集中執行的服務中斷。使用多個副本執行工作負載。備用資源數量應高於並行節點數量。

為避免升級作業停滯，升級至 1.32 版的排空程序不會遵守 Pod 中斷預算 (PDB)。工作負載可能會以效能降低的狀態執行，且服務副本數量最少為 total replica number - concurrent upgrade number。

API 相容性

如要瞭解 API 相容性，請在升級次要版本時，檢查工作負載 API 是否與新版 Kubernetes 次要版本相容。如有需要，請將工作負載升級至相容版本。在可行的情況下，GKE Enterprise 工程團隊會提供相關說明，協助您找出使用不相容 API 的工作負載，例如已移除的 Kubernetes API。

如果您使用 Cloud Service Mesh、Config Sync、Policy Controller、Config Controller 或其他 GKE Enterprise 元件，請檢查已安裝的版本是否與新版 Google Distributed Cloud 相容。如需 GKE Enterprise 元件版本相容性資訊，請參閱「GKE Enterprise 版本和升級支援情形」。

稽核 Webhook 的使用情形

檢查叢集是否有任何 Webhook，尤其是用於稽核的 Pod 資源，例如 Policy Controller。叢集升級期間的排空程序可能會中斷 Policy Controller Webhook 服務，導致升級作業停滯或耗費很長時間。建議您暫時停用這些 Webhook，或使用高可用性 (HA) 部署。

查看預先發布版功能的使用情形

預覽功能可能會變更，僅供測試和評估。請勿在正式環境叢集使用預先發布版功能。我們無法保證使用預覽功能的叢集可以升級。在某些情況下，我們會明確禁止使用預先發布版功能的叢集升級。

如要瞭解升級相關的破壞性變更，請參閱「版本資訊」。

檢查 SELinux 狀態

如要啟用 SELinux 來保護容器，請務必在所有主機上啟用 Enforced 模式的 SELinux。從 Google Distributed Cloud 1.9.0 版開始，您可以在建立叢集或升級叢集前後啟用或停用 SELinux。Red Hat Enterprise Linux (RHEL) 預設會啟用 SELinux。如果主機停用了 SELinux，或您不確定是否已啟用，請參閱「使用 SELinux 保護容器」一文，瞭解如何啟用。

Google Distributed Cloud 僅支援 RHEL 系統中的 SELinux。

請勿變更 Pod 密度設定

Google Distributed Cloud 支援使用 nodeConfig.PodDensity.MaxPodsPerNode 設定每個節點最多 250 個 Pod。您只能在建立叢集時設定 Pod 密度。您無法更新現有叢集的 Pod 密度設定。升級期間請勿嘗試變更 Pod 密度設定。

確認控制層和負載平衡器節點未處於維護模式

開始升級前，請確認控制層和負載平衡器節點並未處於維護狀態。如有任何節點處於維護模式，升級作業就會暫停，確保控制層和負載平衡器節點集區有足夠的可用性。

Google Distributed Cloud 叢集升級最佳做法 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

升級檢查清單

規劃升級作業

預估時間投入量並規劃維護期間

檢查其他 GKE Enterprise 元件的相容性