排解叢集升級問題

如果 Google Kubernetes Engine (GKE) 控制層或節點集區升級失敗、停滯或導致工作負載出現異常行為，您可能需要排解程序問題。為確保安全性和效能，並解決任何問題，請務必將控制層和節點集區保持在最新狀態，確保環境維持穩定。

如要解決常見的升級問題，建議先監控叢集升級程序。然後尋找解決問題的建議：

平台管理員和營運人員如要診斷升級作業停滯或失敗的根本原因、管理維護政策，以及解決版本不相容問題，請務必詳閱本文資訊。應用程式開發人員可以參考相關指南，瞭解如何解決升級後的工作負載問題，以及工作負載設定 (例如 PodDisruptionBudgets) 如何影響升級時間。如要進一步瞭解 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

監控叢集升級程序

如要更有效解決升級問題，請先瞭解升級程序期間發生了什麼事。GKE 提供多種工具，可讓您掌握這項程序。

在 Google Cloud 控制台中，升級資訊主頁會顯示專案中所有進行中的叢集升級、近期事件的時間表，以及潛在阻礙因素的警告，例如有效的維護排除項目或即將淘汰的版本。如要透過指令列或自動檢查，可以使用 gcloud container operations list 指令取得特定升級作業的狀態。詳情請參閱「掌握叢集升級情況」。

如要進行更詳細的調查，Cloud Logging 是主要資訊來源。GKE 會在 Cloud Logging 中記錄控制層和節點集區升級程序的詳細資訊。這包括追蹤主要升級作業的高階稽核記錄，以及更精細的記錄，例如 Kubernetes 事件和節點元件的記錄，可顯示特定錯誤的詳細資訊。

以下各節說明如何使用記錄檢視器或 gcloud CLI 查詢這些記錄。詳情請參閱檢查升級記錄。

透過稽核記錄找出升級作業

如果您不知道哪個升級作業失敗，可以使用 GKE 稽核記錄。稽核記錄會追蹤管理動作，並提供升級啟動時間和最終狀態的權威記錄。在記錄檔探索工具中使用下列查詢，找出相關作業。

事件類型 記錄查詢
控制層自動升級 
resource.type="gke_cluster"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

將 CLUSTER_NAME 替換為要調查的叢集名稱。

這項查詢會顯示目標控制層版本和先前的控制層版本。
控制層手動升級 
resource.type="gke_cluster"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

 
節點集區自動升級 (僅限目標版本) 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

將 NODEPOOL_NAME 替換為叢集所屬的節點集區名稱。
節點集區手動升級 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

如要找出先前的節點集區版本，請查看 Kubernetes API 記錄：

resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.methodName="nodes.patch"

在 GKE 記錄中查看詳細的錯誤訊息

稽核記錄會顯示失敗的作業和時間，您可以搜尋同一時間前後 GKE 元件的詳細錯誤訊息。這些記錄可能包含升級失敗的具體原因，例如設定錯誤的 PodDisruptionBudget 物件。

舉例來說，在稽核記錄中找到失敗的 UPGRADE_NODES 作業後，您可以使用時間戳記縮小搜尋範圍。在記錄檔探索工具中輸入下列查詢，然後使用時間範圍選取器，將焦點放在發生失敗的時間：

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

更改下列內容：

  • CLUSTER_NAME：叢集名稱。
  • NODE_NAME：要檢查錯誤的叢集內節點名稱。

使用 gcloud CLI 查看升級事件

除了記錄檔探索工具，您也可以使用 gcloud CLI 指令查看升級事件。

如要尋找控制平面升級，請執行下列指令：

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

輸出結果會與下列內容相似：

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

這項輸出內容包含下列值：

  • LOCATION：叢集的 Compute Engine 區域或可用區 (例如 us-central1 或 us-central1-a)。
  • CLUSTER_NAME：叢集名稱。

如要查看節點集區升級，請執行下列指令：

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

輸出結果會與下列內容相似：

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

範例：使用記錄檔排解控制層升級問題

以下範例說明如何使用記錄，排解控制層升級失敗的問題：

  1. 前往 Google Cloud 控制台的「Logs Explorer」頁面。

    前往記錄檔探索工具

  2. 在查詢窗格中輸入下列查詢，篩選控制層升級記錄：

    resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

    將 CLUSTER_NAME 替換為要調查的叢集名稱。

  3. 點選「執行查詢」

  4. 查看記錄輸出內容，瞭解下列資訊：

  5. 確認升級已開始：尋找您啟動升級時的近期 UPGRADE_MASTER 事件。如果出現這些事件，表示升級程序是由您或 GKE 觸發。

    • 驗證版本：檢查下列欄位，確認先前和目標版本：

      • protoPayload.metadata.previousMasterVersion：顯示升級「前」的控制層版本。

      • protoPayload.metadata.currentMasterVersion：顯示 GKE 嘗試將控制層升級至的版本。

        舉例來說，如果您打算升級至 1.30.1-gke.1234 版，但意外指定了 1.30.2-gke.4321 版 (較新版本，可能與工作負載不相容)，查看這兩個欄位就會發現差異。或者，如果 currentMasterVersion 欄位在一段時間後仍顯示舊版，表示升級作業未能套用新版本。

    • 尋找錯誤：檢查是否有重複的 UPGRADE_MASTER 事件或其他錯誤訊息。如果作業記錄停止，但未指出完成或失敗，這項發現就表示有問題。

從記錄檔中找出特定錯誤或行為後，您可以使用該資訊在本指南中尋找適當的解決方案。

排解節點集區升級時間比平常長的問題

如果節點集區升級時間超出預期，請嘗試下列解決方案：

  1. 檢查 Pod 資訊清單中的 terminationGracePeriodSeconds 值。這個值定義 Kubernetes 等待 Pod 正常關閉的最長時間。如果值較高 (例如幾分鐘)，Kubernetes 會等待每個 Pod 的完整時間，因此升級時間可能會大幅延長。如果這個延遲時間造成問題，建議您縮減值。

  2. 檢查 PodDisruptionBudget 物件。節點排空時，GKE 最多會等待一小時，以便從每個節點中正常逐出工作負載。如果 PodDisruptionBudget 物件過於嚴格，可能會導致正常逐出作業永遠無法成功。在這種情況下，GKE 會利用整整一小時的緩衝期，嘗試排空節點，最後逾時並強制升級。如果多個節點都發生這種延遲情形，就會導致整體叢集升級作業緩慢。如要確認是否為限制性 PodDisruptionBudget 物件導致升級速度緩慢，請使用記錄檔探索工具：

    1. 前往 Google Cloud 控制台的「Logs Explorer」頁面。

      前往記錄檔探索工具

    2. 在查詢窗格中，輸入下列查詢：

      resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")

    3. 點選「執行查詢」

    4. 查看記錄輸出內容。如果問題是由 PodDisruptionBudget 物件所致，輸出內容會類似下列內容：

      resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}

    5. 確認 PodDisruptionBudget 物件是造成問題的原因後，請列出所有 PodDisruptionBudget 物件，並確認設定是否適當：

      kubectl get pdb --all-namespaces

      輸出結果會與下列內容相似：

      NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d

      在這個範例中，名為 one_pdb 的 PodDisruptionBudget 至少需要三個可用的 Pod。因為在升級期間逐出 Pod 只會留下兩個可用的 Pod，這項動作會違反預算，導致升級停滯。

      如果 PodDisruptionBudget 物件運作正常，則無須採取任何行動。如果不是，請考慮在升級期間放寬 PodDisruptionBudget 設定。

  3. 檢查節點親和性。如果節點不符合必要標籤，限制性規則會禁止將 Pod 重新排程至可用節點，導致升級作業變慢。如果節點標籤正確，但叢集容量不足以代管新 Pod，節點親和性可能會限制可同時升級的節點數量，因此在升級期間，這個問題特別嚴重。

  4. 確認您是否使用短期升級策略。對於彈性啟動節點，以及在執行 GKE 1.32.2-gke.1652000 以上版本的叢集上僅使用佇列佈建的節點，GKE 會採用短期升級策略。如果使用這項升級策略，升級作業最多可能需要七天。

  5. 檢查您是否使用延長時間的 Pod (適用於 Autopilot 叢集)。升級期間，GKE 必須先排空節點中的所有 Pod，才能完成程序。不過，在 GKE 啟動的升級作業期間，GKE 最多會保留延長時限的 Pod 七天，不會將其逐出。這項保護措施可防止節點耗盡電力。GKE 只會在該時間範圍結束後強制終止 Pod，而單一節點的這段重大延遲 (可能長達數天)，可能會導致 Autopilot 叢集中更多節點的升級作業延遲。

  6. 由於管理這些磁碟區生命週期需要時間，因此附加的持續性磁碟區可能會導致升級程序比平常更久。

  7. 檢查叢集自動升級狀態。如果原因是 SYSTEM_CONFIG，表示基於技術或業務原因，自動升級作業已暫時暫停。如果看到這個原因，建議您不要手動升級，除非有此需要。

排解節點集區升級未完成的問題

有時 GKE 無法完成節點集區升級，導致節點集區部分升級。升級不完整的可能原因如下：

  • 升級已手動取消。
  • 升級失敗的原因包括新節點無法註冊、IP 位址用盡或資源配額不足。
  • GKE 已暫停升級。舉例來說，如果某個版本有已知問題，或是在 Google 發起的特定維護期間，系統可能會暫停升級。
  • 如果您使用自動升級功能，維護時段會在升級完成前結束。或者，升級完成前已開始維護排除期。詳情請參閱「維護期間導致節點更新無法完成」。

節點集區部分升級時，節點會執行不同版本。如要解決這個問題，並確認節點集區中的所有節點都執行相同版本，請繼續升級或復原升級。

不過，大量升級策略和藍綠升級策略與維護期間的互動方式不同：

  • 升級作業：如果升級作業超出維護期間，系統會暫停作業。升級作業會在下一個預定維護期間自動繼續執行。
  • 藍綠升級：升級作業會持續進行，直到完成為止，即使超出維護時段也沒關係。藍綠升級提供精細的升級步調控制，包括批次和節點集區浸泡時間等功能，而額外的節點集區有助於確保工作負載維持運作。

排解非預期的自動升級行為

有時叢集自動升級的過程可能不如預期。下列各節有助於解決下列問題：

啟用節點自動升級功能時，叢集無法升級

如果未停用節點自動升級功能，但系統未升級，請嘗試下列解決方案：

  1. 如果您使用發布版本，請確認節點自動升級功能未遭封鎖。 如果叢集已註冊發布版本，您主要可透過 maintenancePolicy 控制自動升級作業。這可能會導致升級作業無法啟動，或中斷進行中的升級作業。有效的維護作業排除時段可能會完全阻擋升級作業，而維護期間的時間點可能會導致中斷。請檢查maintenancePolicy，判斷問題是否出在下列任一設定：

    gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

    更改下列內容：

    • CLUSTER_NAME：要說明節點集區的叢集名稱。
    • PROJECT_ID：叢集的專案 ID。
    • LOCATION：叢集的 Compute Engine 區域或可用區 (例如 us-central1 或 us-central1-a)。

    輸出結果會與下列內容相似：

    …
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…

    在輸出結果中，查看 maintenancePolicy 區段是否符合下列兩項條件：

    • 如何查看升級作業是否遭到封鎖：尋找具有 NO_MINOR_OR_NODE_UPGRADES 範圍的有效 maintenanceExclusion。這項設定通常會禁止 GKE 啟動新的升級作業。
    • 如要查看升級是否中斷：請檢查 dailyMaintenanceWindow 或 maintenanceExclusions 的時間表。如果升級作業超出排定的時間範圍，GKE 會暫停升級，導致部分升級。如要進一步瞭解部分升級，請參閱「排解升級不完整的問題」一節。

    如要解決這些問題，您可以等待排除作業結束、移除排除作業，或調整維護期間，讓升級作業有更多時間完成。

  2. 如果您未使用發布版本，請確認節點集區仍啟用自動升級功能：

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION

    將 NODE_POOL_NAME 替換為要說明的節點集區名稱。

    如果這個節點集區已啟用節點集區自動升級功能，autoUpgrade 欄位中的輸出內容如下：

    management:
  autoUpgrade: true

    如果 autoUpgrade 設為 false，或沒有這個欄位，請啟用自動升級。

  3. 即使發行說明中提及升級，升級作業可能尚未在叢集所在的區域或可用區推出。GKE 升級作業會在多天內逐步推出 (通常為四天以上)。升級作業抵達您所在的區域或地帶後，只會在核准的維護期間開始。舉例來說，推出作業可能在推出第一天就抵達叢集的區域，但叢集的下一個維護期間要到第七天才開始。在這種情況下，GKE 不會升級叢集，直到第七天為止。詳情請參閱 GKE 發布時間表。

如果未啟用自動升級功能，叢集會自動升級

為確保 GKE 環境的可靠性、可用性、安全性和效能，即使您未使用自動升級功能，GKE 也可能會自動升級叢集。

基於下列幾項重大原因，GKE 可能會略過維護期間、排除項目或已停用的節點集區自動升級功能，執行必要升級：

  • 控制層執行的 GKE 版本已達支援期限的叢集。如要確認叢集是否即將終止支援，請參閱「發布管道的預估時間表」。
  • 叢集內的節點執行的 GKE 版本已達支援期限。
  • 叢集處於執行狀態，但長時間沒有任何活動。舉例來說，如果叢集沒有 API 呼叫、沒有網路流量，且沒有主動使用子網路，GKE 可能會將其視為已遭棄用。
  • 叢集持續不穩定，不斷在運作狀態之間循環。舉例來說，如果狀態從執行中變成降級、修復或暫停，然後又回到執行中，但問題並未解決，就會形成迴圈。

如果您發現系統自動升級，且擔心升級對叢集造成影響，請與 Cloud Customer Care 聯絡以尋求協助。

排解升級失敗問題

如果升級失敗，GKE 會產生錯誤訊息。下列各節說明下列錯誤的原因和解決方法：

錯誤：kube-apiserver 運作狀態不良

有時，手動升級叢集 GKE 版本的控制層時，可能會看到下列錯誤訊息：

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

這則訊息會顯示在 gcloud CLI，以及 gke_cluster 和 gke_nodepool 資源類型記錄項目中。

如果使用者部署的某些許可控制器 Webhook 會阻礙系統元件建立正常運作所需的寬鬆 RBAC 角色，就會發生這個問題。

在控制層升級期間，GKE 會重新建立 Kubernetes API 伺服器 (kube-apiserver) 元件。如果 Webhook 封鎖 API 伺服器元件的 RBAC 角色，API 伺服器將無法啟動，叢集升級也無法完成。即使 Webhook 運作正常，仍可能導致叢集升級失敗，因為新建立的控制層可能無法連上 Webhook。

Kubernetes 會自動調解最新次要版本中的預設系統 RBAC 角色和預設政策。新版 Kubernetes 有時會變更系統角色的預設政策。

為執行這項調解作業，GKE 會在叢集中建立或更新 ClusterRole 和 ClusterRoleBinding。如果您的 Webhook 會攔截並拒絕建立或更新要求，原因是預設 RBAC 政策使用的權限範圍，API 伺服器就無法在新次要版本上運作。

如要找出失敗的 Webhook，請查看 GKE 稽核記錄，瞭解包含下列資訊的 RBAC 呼叫：

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

在這個輸出內容中，RBAC_RULE 是 RBAC 角色的完整名稱，例如 rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler。

記錄檔會以以下格式顯示失敗的 Webhook 名稱：

admission webhook WEBHOOK_NAME denied the request

如要解決這個問題，請嘗試下列解決方案：

  1. 檢查 ClusterRole，確認不會過於嚴格。您的政策不應封鎖 GKE 的要求，以免建立或更新具有預設 system: 前置字元的 ClusterRole。
  2. 調整 Webhook，使其不再攔截建立及更新系統 RBAC 角色時的要求。
  3. 停用 Webhook。

錯誤：DeployPatch 失敗

有時叢集升級作業會失敗，並顯示下列錯誤：

DeployPatch failed

如果 Kubernetes 控制層持續 20 分鐘以上處於異常狀態，就可能發生這個錯誤。

由於控制層會重試作業，直到成功為止，因此這類錯誤通常是暫時性的。如果升級作業持續失敗並顯示這項錯誤，請與 Cloud Customer Care 團隊聯絡。

排解升級後的問題

如果升級完成後發生非預期行為，請參閱下列各節的疑難排解指南，解決下列常見問題：

因破壞性變更而發生非預期行為

如果升級作業順利完成，但升級後發生非預期行為，請參閱 GKE 版本資訊，瞭解與叢集升級版本相關的錯誤和重大變更。

標準叢集升級後遭到驅逐的工作負載

如果符合下列所有條件，叢集升級後工作負載可能遭到逐出：

  • 叢集控制層執行新版 GKE 時，系統工作負載需要更多空間。
  • 現有節點的資源不足，無法執行新的系統工作負載和現有工作負載。
  • 叢集已停用叢集自動配置器。

如要解決這個問題，請嘗試下列解決方案：

  1. 為現有節點集區啟用自動調度資源功能。
  2. 啟用節點自動佈建功能。
  3. 建立新的節點集區。
  4. 擴充現有節點集區。

設定節點可分配資源後，Pod 卡在 Pending 狀態

如果您已設定節點可分配資源，節點版本升級有時會導致處於 Running 狀態的 Pod 卡在 Pending 狀態。這項變更通常是因為升級後的節點會耗用略有不同的系統資源，或是因為重新排定的 Pod 現在必須符合新節點或修改節點的節點可分配限制，條件可能更嚴格。

如果 Pods 在升級後顯示 Pending 狀態，請嘗試下列解決方法：

  1. 確認 Pod 的 CPU 和記憶體要求未超出尖峰用量。由於 GKE 會預留 CPU 和記憶體供額外負荷使用，因此 Pod 無法要求這些資源。如果 Pod 要求使用的 CPU 或記憶體超過實際用量，其他 Pod 就無法要求這些資源，叢集也可能無法充分發揮效用。詳情請參閱 Kubernetes 說明文件中的「如何排定具有資源要求的 Pod 時間」。
  2. 建議增加叢集大小。
  3. 如要確認升級是否為造成這個問題的原因，請降級節點集區，還原升級。
  4. 設定叢集，將 Kubernetes 排程器指標傳送至 Cloud Monitoring，並查看排程器指標。監控這些指標可判斷 Pod 是否有足夠的執行資源。

排解版本和相容性問題

為叢集的所有元件維持支援和相容的版本，是確保穩定性和效能的必要條件。下列各節提供指引，說明如何找出並解決可能影響升級程序的版本和相容性問題。

檢查控制層和節點版本是否不相容

控制層和節點之間的版本差異可能會導致叢集不穩定。根據 GKE 版本差異政策，控制層只會與最多兩個次要版本的節點相容。舉例來說，1.19 控制層可與 1.19、1.18 和 1.17 節點搭配運作。

如果節點超出支援期限，可能會發生重大相容性問題。這些問題通常與 API 相關，舉例來說，舊節點上的工作負載可能使用已淘汰或從新版控制層移除的 API 版本。如果工作負載不相容而導致通訊中斷，也可能造成更嚴重的故障，例如網路路徑中斷，導致節點無法向叢集註冊。

GKE 團隊會定期代您升級叢集控制層。控制層會升級至較新的 Kubernetes 穩定版本。為確保節點與升級後的控制層保持相容，節點也必須保持在最新狀態。根據預設，GKE 會處理這項升級作業，因為叢集的節點已啟用自動升級功能，建議您不要停用這項功能。如果叢集節點停用自動升級功能，且您未手動升級節點，控制層最終會與節點不相容。

如要確認控制層和節點版本是否不相容，請檢查叢集控制層和節點集區執行的 Kubernetes 版本：

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

更改下列內容：

  • CLUSTER_NAME：要說明節點集區的叢集名稱。
  • PROJECT_ID：叢集的專案 ID。
  • LOCATION：叢集的 Compute Engine 區域或可用區 (例如 us-central1 或 us-central1-a)。

輸出結果會與下列內容相似：

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

在本例中，控制層版本和節點集區版本不相容。

如要解決這個問題，請手動將節點集區升級至與控制層相容的版本。

如果擔心升級程序會中斷受影響節點上執行的工作負載，請完成下列步驟，將工作負載遷移至新的節點集區：

  1. 建立新的節點集區，並使用相容版本。
  2. 隔離現有節點集區的節點。
  3. 選用步驟：更新在現有節點集區上執行的工作負載，為標籤 cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME 新增 nodeSelector。將 NEW_NODE_POOL_NAME 替換為新節點集區的名稱。這項動作可確保 GKE 將這些工作負載放置在新節點集區的節點上。
  4. 清空現有節點集區。
  5. 確認工作負載在新節點集區中順利執行。 如果可以，請刪除舊的節點集區。如果發現工作負載中斷，請取消隔離現有節點集區中的節點，並清空新節點，藉此重新排程現有節點上的工作負載。

節點 CPU 使用率高於預期

您可能會遇到部分節點使用的 CPU 超過執行中 Pod 預期用量的問題。

如果您使用手動升級，且叢集或節點尚未升級至支援的版本，就可能發生這個問題。請參閱版本資訊，確認您使用的版本是否可用且受支援。

後續步驟