排解叢集升級問題

Autopilot Standard

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

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

• 節點集區升級時間比平常久。
• 節點集區升級未完成。
• 非預期的自動升級行為。
• 升級失敗並顯示特定錯誤訊息。
• 升級完成後發生問題。
• 版本相容性問題。

對於想要診斷升級停滯或失敗根本原因、管理維護政策，以及解決版本不相容問題的平台管理員和作業人員來說，這項資訊非常重要。應用程式開發人員可以參閱指南，瞭解如何解決升級後的工作負載問題，以及 PodDisruptionBudgets 等工作負載設定如何影響升級時間。如要進一步瞭解我們在 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

監控叢集升級程序

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

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

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

以下各節說明如何使用 Logs Explorer 或 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 作業後，您可以使用時間戳記縮小搜尋範圍。在 Logs Explorer 中輸入下列查詢，然後使用日期範圍選取器，聚焦於發生失敗的時間：

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

更改下列內容：

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

使用 gcloud CLI 查看升級事件

除了 Logs Explorer，您也可以使用 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」頁面。

   前往 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 物件是否導致升級速度緩慢，請使用 Logs Explorer：

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

      前往 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 發起的特定維護期間，就可能發生這種暫停情況。
• 如果您使用自動升級功能，維護期間會在升級完成前結束。或者，維護排除期在升級完成前開始。詳情請參閱「維護期間導致節點更新無法完成」。

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

節點升級策略如何搭配維護期間運作

突增升級策略和藍綠升級策略與維護期間的互動方式不同：

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

如要進一步瞭解特定作業如何搭配維護政策運作，請參閱「遵守維護政策」資料欄，這些資料欄位於「GKE 叢集變更類型」一文的表格中。

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

有時叢集自動升級作業可能不如預期。以下各節將協助您解決下列問題：

• 啟用自動升級功能後，叢集無法升級
• 未啟用自動升級功能時，叢集會自動升級

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

如果您未停用節點自動升級功能，但升級作業未執行，請嘗試下列解決方案：

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 不健康
• 錯誤：DeployPatch 失敗

錯誤：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 建立或更新 ClusterRole 的要求，這些 ClusterRole 具有預設的 system: 前置字元。
2. 調整 Webhook，使其不再攔截建立及更新系統 RBAC 角色的要求。
3. 停用 Webhook。

錯誤：DeployPatch 失敗

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

DeployPatch failed

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

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

疑難排解升級完成後的問題

如果升級完成後發生非預期行為，請參閱下列各節，瞭解如何排解常見問題：

• 破壞性變更導致非預期行為
• 升級標準叢集後遭驅逐的工作負載
• Pod 卡在「Pending」狀態
• 節點 CPU 使用率高於預期

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

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

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

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

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

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

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

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

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

如果升級後 Pod 的狀態為 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 預期的問題。

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

後續步驟

• 如果無法在文件中找到問題的解決方案，請參閱「取得支援」一文，取得進一步協助，包括下列主題的建議：

  • 與 Cloud Customer Care 聯絡，建立客服案件。
  • 在 StackOverflow 上提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。你也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
  • 使用公開 Issue Tracker 開啟問題或功能要求。