Google Distributed Cloud 的結構化升級最佳做法，可協助您盡可能減少服務中斷情形，並降低營運風險。升級前驗證有助於確保叢集和工作負載在各版本轉換期間保持穩定。
如果環境橫跨測試、開發和正式層級，請從最不重要的層級開始，依序升級。在每個階段驗證叢集健康狀態和工作負載行為，有助於在更新正式環境系統前找出潛在問題。
升級檢查清單
建議您遵循本文件中的所有最佳做法。請使用下列檢查清單追蹤進度。清單中的每個項目都會連結至本文的相關章節，提供更多資訊：
完成這些檢查後，即可開始升級程序。監控進度，直到所有叢集都成功升級。
規劃升級
更新可能會造成干擾。開始升級前，請仔細規劃，確保環境和應用程式已準備就緒。
預估所需時間並規劃維護期間
升級叢集所需的時間，取決於節點數量和節點上執行的工作負載密度。為順利完成叢集升級，請設定足夠的維護期間。
如要粗略估算升級時間，請使用 10 minutes * the number of
nodes 做為單一並行節點升級時間。
舉例來說，如果叢集有五十個節點，總升級時間約為五百分鐘：10 minutes * 50 nodes = 500 minutes。
查看其他 Google Cloud 產品的相容性
如果叢集執行 Cloud Service Mesh、Config Sync 或 Policy Controller，請參閱「版本和升級支援」，並在升級前後確認 Google Distributed Cloud 支援的版本。
相容性檢查會依據 Cloud Service Mesh、Config Sync 或 Policy Controller 部署的管理員或使用者叢集進行。
檢查叢集資源使用率
為確保 Pod 可以在節點耗盡時撤離，且升級中的叢集有足夠資源可管理升級作業，請檢查叢集目前的資源用量。如要查看叢集的資源使用情形，請使用 Google Cloud Observability 中的自訂資訊主頁。
您可以使用 kubectl top nodes 等指令取得目前的叢集資源用量，但資訊主頁可以提供更詳細的資源消耗情況。這項資源用量資料可協助您判斷何時升級造成的干擾最少，例如週末或晚上，具體取決於執行的工作負載和用途。
管理員叢集的升級時間可能不如使用者叢集重要，因為管理員叢集升級通常不會導致應用程式停機。不過，在開始升級管理員叢集之前，仍應檢查可用資源。此外，升級管理員叢集可能會有風險，因此建議在非活躍使用期間進行，此時對叢集的管理存取權較不重要。
管理員叢集控制層資源
所有升級控制器和工作都會在管理員叢集控制層節點中執行。請檢查這些控制層節點的資源消耗量，瞭解可用的運算資源。升級程序通常需要 1000 毫核心 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，直到所有使用者叢集都升級至與管理員叢集相同的版本。
如果控制層節點在升級期間沒有額外的運算資源，您可能會看到 anthos-cluster-operator、capi-controller-manager、cap-controller-manager 或 cap-kubeadm-bootstraper 等 Pod 處於 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.36 的排空程序不會遵循 Pod 中斷預算 (PDB)。工作負載可能會以效能降低的狀態執行，且最少提供服務的副本為 total
replica number - concurrent upgrade number。
API 相容性
如要確認 API 相容性，請在升級子版本時，檢查工作負載 API 與新版 Kubernetes 子版本的相容性。如有需要，請將工作負載升級至相容版本。GKE 工程團隊會盡可能提供操作說明，協助您找出使用不相容 API (例如已移除的 Kubernetes API) 的工作負載。
如果您使用 Cloud Service Mesh、Config Sync、Policy Controller，請確認安裝的版本與新版 Google Distributed Cloud 相容。如要瞭解版本相容性資訊，請參閱「版本和升級支援」。
稽核 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 密度設定。
確認控制層和負載平衡器節點未處於維護模式
開始升級前，請確認控制層和負載平衡器節點並未處於維護狀態。如果有任何節點處於維護模式，升級作業就會暫停，確保控制層和負載平衡器節點集區有足夠的可用性。