Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

排解自訂 ComputeClass 問題

Autopilot Standard

本文說明如何排解 GKE 工作負載無法在自訂 ComputeClass 定義的節點上排程，或叢集自動配置器未佈建預期機型的問題。

本文適用對象為應用程式開發人員、平台管理員和操作人員，他們會使用自訂 ComputeClass，在 GKE 中管理工作負載排程和節點集區自動建立作業。如要進一步瞭解 Google Cloud 內容中提及的常見角色和工作範例，請參閱「常見的 GKE 使用者角色和工作」。

基本概念

為協助您排解問題，請務必熟悉下列 GKE 元件和機制：

自訂 ComputeClass：GKE 專屬資源，可讓您定義自動調度資源的優先節點設定清單。詳情請參閱「關於自訂 ComputeClass」。
叢集自動配置器：根據工作負載需求，自動在叢集中新增或移除節點的元件。詳情請參閱「關於 GKE 叢集自動調度資源」。
自動建立節點集區：GKE 叢集自動配置器會根據工作負載需求，自動建立及管理節點集區。詳情請參閱「關於節點集區自動建立功能」。
備用邏輯：叢集自動配置器會先嘗試佈建符合最高優先順序規則的節點。詳情請參閱「選擇備用運算優先順序」。

本文會依序介紹疑難排解步驟，從基本檢查到進階設定都有。為進行更全面的診斷，建議您依序執行這些步驟。或者，如果您遇到特定問題，請參閱下表中的相關連結：

問題	疑難排解步驟
要求自訂 ComputeClass 的 Pod 卡在 `Pending` 狀態	執行基本診斷檢查檢查 Pod 排程限制節點集區設定 (適用於 Standard 叢集) 分析叢集自動配置器待處理的 Pod 指標
叢集自動配置器未建立與自訂 ComputeClass 相符的新節點	驗證自訂 ComputeClass 設定驗證節點集區自動建立設定分析叢集自動配置器待處理的 Pod 指標分析節點佈建失敗情形
叢集自動配置器建立預設機型，而非特殊類型	分析自動調整資源配置器回退行為
`kubectl describe computeclass` 指令的輸出內容顯示狀態不良	驗證自訂 ComputeClass 設定
工作負載不會遷移至優先順序較高的節點	確認叢集自動配置器的一般健康狀態
GPU 或 Spot VM 工作負載有排程問題	檢查 Pod 排程限制驗證 GPU 或 Spot VM 設定分析自動配置器備用行為

超出範圍的問題

本文件未說明下列問題：

一般 GKE 網路問題，例如 Pod 對 Pod 連線能力或 Service 負載平衡。
與水平 Pod 自動配置器 (HPA) 或垂直 Pod 自動配置器 (VPA) 相關的問題。
與自訂 ComputeClass 機制無關的問題，例如應用程式層級錯誤，或與排程限制無關的 PersistentVolume 問題。
與 ComputeClass 備用邏輯無直接關聯的配額或資源無法使用問題。

找出預留位置變數

如要自訂這份文件中的指令，請在「Variable」欄中輸入特定值。編輯後的值會自動同步到所有程式碼區塊和指令。

變數	說明
`PROJECT_ID`	您的 Google Cloud 專案 ID。
`LOCATION`	叢集所在的 Compute Engine 區域或可用區。
`CLUSTER_NAME`	叢集名稱。
`NODE_POOL_NAME`	要檢查的節點集區名稱 (如果適用於 Standard 叢集)。
`CUSTOM_COMPUTECLASS_NAME`	Pod 要求的自訂 ComputeClass 名稱。
`NAMESPACE`	無法排程的 Pod 命名空間。
`POD_NAME`	無法排程的 Pod 名稱。

事前準備

如要取得執行本文件所述工作所需的權限，請要求管理員在 Google Cloud 專案中授予您下列 IAM 角色：

如要存取 GKE 叢集： Kubernetes Engine 叢集檢視者 (roles/container.viewer)。
如要查看記錄：記錄檢視器 (roles/logging.viewer)。
如要管理 GKE 叢集：Kubernetes Engine 管理員 (roles/container.admin)。

如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和組織的存取權」。

您或許也能透過自訂角色或其他預先定義的角色，取得必要權限。

如要設定 kubectl 與叢集通訊，請執行下列指令：

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

執行基本診斷檢查

請確認核心元件設定正確，且叢集支援自訂 ComputeClass。

驗證 Pod 狀態和選取器

確認 Pod 處於 Pending 狀態，並正確要求自訂 ComputeClass。

列出處於 Pending 狀態的 Pod：

kubectl get pods --all-namespaces -o wide | grep Pending

檢查 Pod 規格的 nodeSelector 欄位：

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.nodeSelector}'

評估結果

輸出內容顯示標籤：nodeSelector 欄位已正確設定 cloud.google.com/compute-class 標籤。
輸出內容未顯示標籤：
- 解讀：工作負載部署設定中的 cloud.google.com/compute-class 標籤可能缺少 nodeSelector 欄位，或該欄位有誤。
- 解決方法：修改工作負載的 YAML 檔案 (例如 Deployment 或 Job)，在 spec.template.spec 區段中加入 nodeSelector 欄位。

確認叢集版本相容性

自訂 ComputeClass 須使用 GKE 1.30.3-gke.1451000 以上版本。確認叢集執行的版本支援自訂 ComputeClass。

檢查叢集版本：

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

評估結果

版本 1.30.3-gke.1451000 以上：叢集版本支援自訂 ComputeClass。
1.30.3-gke.1451000 之前的版本：
- 解讀：叢集尚未升級至支援自訂 ComputeClass 的版本。
- 解決方法：您必須升級叢集，才能使用自訂 ComputeClass。

驗證為自訂 ComputeClass 佈建的節點

如要檢查叢集中是否有與 ComputeClass 相關聯的節點，請列出與 ComputeClass 標籤相符的節點：

kubectl get nodes -l cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

如果輸出內容為 No resources found，表示沒有與 ComputeClass 相關聯的節點。確認工作負載確實選取該 ComputeClass，並檢查自動調度資源事件是否有向上擴充錯誤。

驗證自訂 ComputeClass 設定

自訂 ComputeClass 資源設定錯誤，可能會導致 Pod 無法排程，或 GKE 無法正確佈建節點。

檢查 ComputeClass 健康狀態和狀態

確認 GKE 回報自訂 ComputeClass 的健康狀態良好。

列出所有ComputeClass資源：
```
kubectl get computeclass
```

說明特定 ComputeClass 資源：

kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

評估結果

健康狀態顯示 True：自訂 ComputeClass 運作正常。以下是健全的自訂 ComputeClass 範例：

Status:
  Conditions:
    Last Transition Time:  2024-01-19T17:18:48Z
    Message:               CCC is healthy.
    Reason:                Health
    Status:                True
    Type:                  Health

健康狀態顯示 False：
- 解讀：自訂 ComputeClass 狀況不佳。查看輸出內容中的 Message 和 Reason 欄位，找出問題。
- 解決方法：根據輸出內容中的 Reason 欄位執行對應動作：
  - NodePoolNotExist：確認參照的節點集區存在，或更新 ComputeClass 以參照現有的節點集區。
  - ReservationUnusable：檢查參照預留項目的設定和用量。
  - Invalid machine type：更新 ComputeClass，使用叢集區域或可用區支援的機型。

驗證 `unsatisfiable` 政策

whenUnsatisfiable 欄位會決定無法滿足任何優先順序規則時的行為。

查閱政策：

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

檢查輸出內容中的 spec.whenUnsatisfiable 欄位。這個欄位可包含下列其中一個值：

DoNotScaleUp：如果無法建立偏好的節點，Pod 會維持 Pending 狀態。
ScaleUpAnyway：如果偏好的節點無法使用，Pod 可能會在預設節點類型 (例如 E2 系列) 上執行。

評估結果

whenUnsatisfiable 政策的效果取決於其值：

如果值為 DoNotScaleUp：
- 解讀：如果無法滿足任何優先順序規則，系統就會採取這項預期行為，原因可能是資源無法使用或配額限制。如果 Pod 必須等待特定硬體，這個值就正確。
- 解決方法：如果執行工作負載比在特定硬體上執行更重要，請將政策變更為 ScaleUpAnyway。
如果值為 ScaleUpAnyway：
- 解讀：這是預期行為。偏好的節點無法使用，因此 GKE 會改用預設節點類型。
- 解決方法：如果 Pod 不得在預設節點類型上執行，請將政策變更為 DoNotScaleUp。
預設行為：如果您尚未指定 whenUnsatisfiable 欄位的值，且使用的 GKE 版本低於 1.33，則政策預設為 ScaleUpAnyway。

以下範例說明如何編輯 ComputeClass 資訊清單中的 whenUnsatisfiable 欄位，藉此更新政策：

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

檢查 Pod 排程限制

確認 Pod 規格與自訂 ComputeClass 佈建的節點屬性相容。

驗證廣告連播資源要求

檢查自訂 ComputeClass 的 priorities 欄位中定義的至少一個機型，是否能滿足 Pod 的 CPU、記憶體和 GPU 要求。

取得 Pod 資源要求：

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.containers[*].resources.requests}'

檢查 cpu、memory 和 GPU 要求 (例如 nvidia.com/gpu) 的輸出內容。

將這些要求與自訂 ComputeClass 的 priorities 欄位中定義的機型進行比較：
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'
```
檢查 machineType 或 machineFamily 欄位的輸出內容。請在機型說明文件中，查看自訂 ComputeClass 內各機型的規格，確認可分配資源是否大於 Pod 的要求。

評估結果

相容資源：Pod 的資源要求小於或等於 ComputeClass 中至少一種機型的可分配資源。
資源超出容量：
- 解讀：Pod 無法排程，因為 ComputeClass 中沒有任何機型提供足夠的 CPU、記憶體或 GPU。如果 nodePoolAutoCreation 欄位設為 true，且 Pod 的記憶體要求超出自動建立的節點集區限制，也可能發生這種情況。
- 解決方法：調整 Pod 的資源要求或自訂 ComputeClass 的機型：
  - 減少 Pod 資源要求：如果資源要求較高，請降低工作負載 YAML 檔案中的 cpu、memory 或 gpu 值。
  - 改用較大的機型：如果 Pod 的要求合理，請修改自訂 ComputeClass 資訊清單中的 spec.priorities 欄位，加入較大的 machineType 或 machineFamily 選項，以滿足 Pod 的需求。例如：
```
spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities
```

檢查是否有衝突的污點和容許

為自訂 ComputeClass 建立的節點會帶有 cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule 汙點。GKE 會自動將這個容忍度新增至 Pod。

不過，GPU 等特殊硬體有額外的汙點，例如 nvidia.com/gpu=present:NoSchedule 汙點。如果 ComputeClass 使用的節點具備專用硬體，Pod 必須容忍這些污點，才能在這些節點上排程。

檢查 Pod 的 tolerations 欄位：

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

評估結果

正確的容忍：已正確設定污點和容忍。
缺少容許度：
- 解讀：缺少容許度會導致 Pod 無法排程到具有專用硬體污點的節點上。舉例來說，如果 ComputeClass 使用 GPU 節點，Pod 可能會缺少 nvidia.com/gpu=present:NoSchedule 容許度。如要瞭解 GPU 專屬需求，請參閱「確認 GPU 設定」。
- 解決方法：在 Pod 規格的 tolerations 欄位中，新增必要的容許條件，以符合 ComputeClass 定義的節點污點。舉例來說，如果是 GPU 節點，請新增 nvidia.com/gpu=present:NoSchedule 容忍度，如下所示：
```
spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec
```

分析叢集自動配置器待處理 Pod 指標

適用的 GKE 版本：1.37 以上版本

如要瞭解要求特定 ComputeClass 的 Pod 為何處於待處理狀態，請使用 Cloud Monitoring 中的 kubernetes.io/autoscaler/cluster_pending_pods_per_ccc 指標。這項指標有助於判斷問題是缺乏適用於 ComputeClass 的節點、佈建問題，還是 Pod 設定本身的問題。這項指標會顯示叢集自動配置器正在處理的 Pod 數量，並依 ComputeClass、待處理原因，以及 Pod 是系統或使用者 Pod 進行細分。

查詢步驟

如要在 Google Cloud 控制台中查詢指標，請按照下列步驟操作：

前往 Google Cloud 控制台的「Metrics Explorer」頁面。
選取「資源類型」k8s_entity。
選取「指標」：kubernetes.io/autoscaler/cluster_pending_pods_per_ccc。
新增「篩選器」entity_type = ComputeClass。
為特定 ComputeClass 新增篩選器：entity_name = "COMPUTECLASS_NAME"。
- 如要查看未使用任何 ComputeClass 的 Pod，請使用 entity_name = "" 篩選。
依 metric.labels.reason 分組依據，查看這些 Pod 的自動配置器狀態。您也可以使用 metric.labels.type 鍵標籤將 Pod 分組。

PromQL 查詢範例

如要查看要求「COMPUTECLASS_NAME」ComputeClass 的待處理使用者 Pod 狀態，請使用下列 PromQL 查詢：

sum by (reason) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    entity_name="COMPUTECLASS_NAME",
    type="user_pod"
  }
)

指標原因

metric.labels.reason 鍵標籤的輸出內容可能包含下列項目：

unable_to_provision：叢集自動配置器遭到封鎖。如果 ComputeClass 的 Pod 處於這個狀態，就無法排定，因為無法建立新節點。請查看控制層中的叢集自動配置器記錄，瞭解 ComputeClass 定義中的缺貨、配額或設定錯誤詳情。同時查看叢集自動配置器可見度事件。
provisioning_in_progress：已觸發節點向上擴充，應符合 ComputeClass 需求。如果 Pod 仍在這裡，節點建立或就緒作業可能會延遲。
unprocessed：叢集自動配置器尚未評估這些 Pod。如果這個數字持續偏高，可能表示自動配置器延遲。
no_action_taken：叢集自動配置器決定不調度這些 Pod 的資源。這可能是因為 ComputeClass 的節點類型無法滿足 Pod 限制，或其他叢集層級限制。檢查 Pod 規格 (kubectl describe pod) 和叢集自動配置器記錄檔。

分析節點佈建失敗情形

適用於 GKE 1.37 以上版本

如要查看 ComputeClass 目前的健康狀態，請參閱「驗證 ComputeClass 健康狀態」。如果發現與 ComputeClass 相關聯的 Pod 處於 unable_to_provision 狀態，表示叢集自動配置器未佈建符合 ComputeClass 需求的新節點。您可以使用 kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc Cloud Monitoring 指標診斷根本原因。

在 Google Cloud 控制台中，依序前往「Monitoring」和「Metrics Explorer」。
選取「Resource type」(資源類型)，例如 k8s_entity。
將「Metric」(指標) 設為「kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc」。
新增篩選器：resource.labels.entity_type = ComputeClass。
為特定 ComputeClass 新增篩選器：entity_name = "CUSTOM_COMPUTECLASS_NAME"。
- 如要查看「未」使用任何 ComputeClass 的 Pod，請使用 entity_name = "" 篩選。
在「Group By」(分組依據) 部分，選取 metric.labels.reason 和 resource.labels.entity_name。
選擇「匯總器」，例如 rate 或 delta。

系統會顯示失敗率或失敗次數的變化，並依據原因細分。

解讀失敗原因

metric.labels.reason 欄位可深入瞭解節點建立失敗的原因。找出失敗的主要原因後，即可採取修正行動。

可能的原因包括：

原因	說明	可能的修正措施
`QUOTA_EXCEEDED`	已達 Google Cloud 配額上限 (例如 CPU、磁碟或 IP 位址)。查看專案配額。	申請提高配額。
`RESOURCE_POOL_EXHAUSTED`	Compute Engine 無法使用；可用區中要求的資源容量不足。	請改用其他機器類型或可用區，修改 ComputeClass，加入備用機型或可用區。使用預留項目。
`IP_SPACE_EXHAUSTED`	節點子網路已無可用 IP 位址。	擴大子網路的主要 IP 位址範圍。
`PERMISSIONS_ERROR`	GKE 服務帳戶缺少建立資源 (例如執行個體、磁碟) 所需的 IAM 權限。	將必要角色授予 GKE 服務帳戶。
`VM_EXTERNAL_IP_ACCESS_POLICY_CONSTRAINT`	組織政策 (`constraints/compute.vmExternalIpAccess`) 禁止建立含外部 IP 的節點。	請查看並修改組織政策或 ComputeClass 節點設定。
`INVALID_RESERVATION`	設定的 Compute Engine 預留項目無效、設定錯誤，或與節點要求不符。	請檢查預留項目設定和 ComputeClass 定義。
`RESERVATION_NOT_FOUND`	指定的 Compute Engine 預留項目名稱不存在。	驗證 ComputeClass 中的預留項目名稱。
`RESERVATION_NOT_READY`	指定預留項目尚未啟用或仍在佈建中。	等待預留項目生效。
`RESERVATION_CAPACITY_EXCEEDED`	預留項目已滿，無法處理要求。	請增加預留項目大小，或改用其他機型。
`RESERVATION_INCOMPATIBLE`	節點設定 (例如機器類型或可用區) 與預留項目的屬性不符。	將 ComputeClass 節點規格與預留項目的屬性對齊。
`AUTOMATIC_RESERVATIONS_NOT_AVAILABLE`	嘗試使用自動預訂功能時發生問題。	請查看記錄，您可能需要與 Cloud Customer Care 聯絡。
`AUTOMATIC_RESERVATIONS_NO_CAPACITY`	自動預留項目容量不足。	可能需要改用手動預留項目或其他機器類型。
`UNSUPPORTED_TPU_CONFIGURATION`	要求的 TPU 設定無效，或所選可用區/專案不支援。	請參閱 TPU 說明文件和 ComputeClass。
`GkePersistentOperationError`	節點建立期間，GKE 控制層發生持續性錯誤。	聯絡 Cloud Customer Care。
`OTHER`	不屬於其他類別的失敗原因。	如需更多詳細資料，請查看控制層的叢集自動配置器記錄。

節點集區設定 (Standard 叢集)

在 GKE Standard 叢集中，手動建立的節點集區必須加上標籤和污點，才能與自訂 ComputeClass 搭配使用。

驗證節點集區標籤和 taint

找出自訂 ComputeClass 中的節點集區。如果自訂 ComputeClass 使用 nodePools 欄位，請記下列出的節點集區名稱：
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

針對您找出的每個節點集區，驗證其設定：

gcloud container node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME
    --location LOCATION
    --format="yaml(config.labels, config.taints)"

評估結果

節點集區設定正確：節點集區具有 cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME 標籤和 cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule 污點。

節點集區設定錯誤：

解讀：節點集區未設定必要的標籤和污點，無法與自訂 ComputeClass 建立關聯。

解決方法： 更新節點集區，加入標籤和汙點：

新增或更新節點標籤：

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

新增或更新節點污點：

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule

驗證節點集區自動建立設定

對於 nodePoolAutoCreation 設為 true 的 Autopilot 和 Standard 叢集，必須正確設定節點集區自動建立功能。

確認已啟用節點集區自動建立功能

檢查自訂 ComputeClass 中的 nodePoolAutoCreation.enabled 欄位是否設為 true：
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

檢查叢集是否已啟用節點集區自動建立功能：

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(autoscaling.enableNodeAutoprovisioning)"

如果停用其中一項，節點集區自動建立功能就不會為自訂 ComputeClass 建立新的節點集區。

評估結果

已啟用節點集區自動建立功能：在 ComputeClass 中，nodePoolAutoCreation.enabled 欄位設為 true，且叢集層級已啟用自動佈建節點功能。
節點集區自動建立功能已停用：
- 解讀：如果 ComputeClass 中的 nodePoolAutoCreation.enabled 欄位值為 false 或遺失，或是叢集層級的自動佈建節點功能已停用，節點集區自動建立功能就會停用。
- 解決方法：啟用節點集區自動建立功能：
  1. 編輯自訂 ComputeClass YAML 檔案，加入 nodePoolAutoCreation: enabled: true：
```
spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true
```
  2. 在叢集層級啟用節點集區自動建立功能，並設定資源限制：
```
gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu=MIN_CPU \
  --autoprovisioning-max-cpu=MAX_CPU \
  --autoprovisioning-min-memory=MIN_MEMORY \
  --autoprovisioning-max-memory=MAX_MEMORY
```

檢查節點集區自動建立功能的資源限制

節點集區自動建立功能有叢集範圍的 CPU 和記憶體限制。如果叢集目前的用量加上新節點的資源超過這些限制，自動建立節點集區功能就不會佈建新節點。

查看資源限制：

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
--format="value(autoscaling.resourceLimits)"

輸出內容會列出 CPU 和記憶體的 resourceType、minimum 和 maximum 欄位 (以 GB 為單位)。

查看自訂 ComputeClass 優先順序中的機型。如要查看 CPU 和記憶體規格，請參閱機器類型說明文件。
判斷叢集中所有節點目前的 CPU 和記憶體總容量。目前容量加上潛在新節點的資源，總和不得超過自動建立節點集區的上限。

評估結果

容量充足：叢集的 CPU 和記憶體容量在資源限制範圍內，足以讓節點集區自動建立功能佈建新節點。
超過上限：
- 解讀：叢集已達 CPU 或記憶體上限，或 ComputeClass 中機型的上限設得太低，因此節點集區自動建立功能無法佈建新節點。
- 解決方法：提高節點集區自動建立的資源限制：
  1. 根據目前用量和未來成長，決定新的上限，包括自訂 ComputeClass 中最大的機型。
  2. 更新自動建立節點集區的資源限制。您可以在一個指令中設定多個資源：
```
gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
  --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB
```

分析自動配置器備用行為

本節將協助您調查外部因素，瞭解叢集自動調整器可能略過偏好選項並使用備援，或無法向上擴充的原因。

自訂 ComputeClasses 會使用優先備用邏輯。如果 Pod 未在符合最高優先順序規則的節點上排程，通常是因為資源無法使用或專案配額等限制。如果 GKE 無法佈建符合特定優先順序規則的節點 (例如 Compute Engine 發生 ZONE_RESOURCE_POOL_EXHAUSTED 或 QUOTA_EXCEEDED 錯誤)，叢集自動配置器會立即嘗試 priorities 清單中的下一個規則。除非使用 TPU 或彈性啟動佈建模式 (支援可設定的延遲時間)，否則 GKE 會立即改用下一個優先順序。

檢查資源是否無法使用

檢查叢集自動配置器記錄或 Compute Engine 代管執行個體群組 (MIG) 錯誤，確認指定可用區中是否有資源無法使用。

選項 1：檢查叢集自動配置器可見度事件

在 Google Cloud 控制台中，依序前往「Cloud Logging」>「Logs Explorer」，然後執行下列查詢，找出可能表示資源無法使用的自動配置器事件：

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

方法 2：檢查 MIG 錯誤

您可以在 Google Cloud 控制台或使用 Cloud Logging 查詢，檢查 MIG 錯誤。

使用 Google Cloud 控制台：
1. 在 Google Cloud 控制台中，依序前往「Compute Engine」 >「Instance groups」(執行個體群組)。
2. 找出無法擴充的節點集區對應的 MIG。
3. 按一下 MIG 名稱，然後前往「Errors」(錯誤) 分頁。尋找指出資源耗盡的訊息。

使用 Cloud Logging 查詢：

前往 Google Cloud 控制台的「Cloud Logging」>「Logs explorer」(記錄檔探索工具)。
執行下列查詢，檢查 MIG 是否發生資源耗盡錯誤：

resource.type="gce_instance"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")

評估結果

資源可用：如果記錄未顯示 ZONE_RESOURCE_POOL_EXHAUSTED 訊息，資源無法使用不太可能是擴充失敗的原因。
無法使用資源：
- 解讀：節點佈建失敗，原因可能是該可用區對特定機器類型 (尤其是 Spot VM 或 GPU) 的需求暫時偏高，或是 Pod 受到 PersistentVolume 親和性限制，只能使用資源不足的可用區。
- 解決方法：資源無法使用是暫時性的問題，但您可以在設定中增加彈性，提高復原能力：
  - 使用多種機型：確保自訂 ComputeClass 的 spec.priorities 欄位包含多種機型或系列，做為備用選項：
```
spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority
```
  - 使用區域叢集：如果叢集是可用區叢集，該可用區的資源無法使用時，叢集就會受到影響。使用區域叢集時，叢集自動配置器會嘗試在區域內其他可能有可用容量的可用區中佈建節點。
  - 使用 Compute Engine 預留項目：對於無法容忍延遲的重要工作負載，請建立 Compute Engine 預留項目，確保特定機型有足夠的容量。

驗證專案配額

確認專案有足夠的配額，可供新節點所需的 CPU、GPU 和 IP 位址等資源使用。

查看自動配置器記錄，瞭解是否有配額錯誤。使用 Cloud Logging 搜尋自動調整規模可見度事件中與配額相關的錯誤訊息：

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"

或者，您也可以使用下列 Cloud Logging 查詢，檢查記錄中是否有 MIG 的配額相關錯誤：

resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
protoPayload.status.message:"QUOTA_EXCEEDED"
severity=ERROR

在 Google Cloud 控制台中查看配額：
1. 在 Google Cloud 控制台中，依序前往「IAM & Admin」(IAM 與管理) >「Quotas」(配額)。
2. 篩選 Compute Engine API 服務。
3. 查看 GKE 叢集所在區域的相關指標用量，例如 CPU、GPU (所有類型) 和使用中的 IP 位址。確認目前用量未達上限。

評估結果

配額低於上限：如果配額用量低於配額上限，且記錄中未發現 QUOTA_EXCEEDED 錯誤，配額上限就不會阻礙擴充。
超過配額：
- 解讀：資源配額不足 (例如 CPU、GPU、IP 位址或 MIG)，因此節點佈建失敗。
- 解決方法：如果專案已達到配額上限，請要求提高配額。

進階設定

GPU、Spot VM 和 Compute Engine 預留項目等設定有各自的特定需求，以及可能發生故障的部分，需要加以檢查。

驗證 GPU 設定

如果是佈建 GPU 節點的自訂 ComputeClass，請驗證自訂 ComputeClass 中的 GPU 設定，並確保 Pod 具有必要的 nvidia.com/gpu 容忍度。

檢查自訂 ComputeClass 的 YAML，確認優先順序規則中是否有 gpu 區塊：

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

gpu 區塊應指定 type 欄位和 count 欄位，例如：

priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1

檢查 Pod 的 GPU 容忍度。凡是需要排程至 GPU 節點的 Pod都必須具有 nvidia.com/gpu 容許度，即使 Pod 本身未要求使用 GPU 也是如此。
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'
```
檢查 spec.tolerations 欄位下方的容忍度。

評估結果

GPU 設定正確：如果 ComputeClass 定義了 GPU type 和 count，且 Pod 包含 nvidia.com/gpu 容忍度，則 GPU 設定正確。以下顯示必要容許度：
```
tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"
```
GPU 設定錯誤：
- 解讀：Pod 可能缺少必要的 nvidia.com/gpu 容忍度、ComputeClass 可能因 GPU 欄位不符而異常，或 GKE 版本可能無法正確處理 GPU 設定。
- 解決方法：執行下列任一操作：
  - 修改工作負載的 YAML 檔案，加入必要的 GPU 容忍度，然後重新套用 YAML 檔案。
  - 升級 GKE 叢集。如果自訂 ComputeClass 狀態不佳，且問題與 GPU 欄位有關，請查看已知問題，並升級至已修補的 GKE 版本，例如 1.31.8-gke.1045000 以上版本。

驗證 Spot VM 設定

如果您使用 Spot VM，請確保 spot: true 設定位於 ComputeClass 資訊清單的正確優先順序規則中。此外，請務必瞭解叢集自動調度程式的定價邏輯。

檢查 ComputeClass 資訊清單：

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

在輸出內容中，尋找 spec.priorities 欄位中的 spot: true，例如：

priorities:
- machineFamily: n2d
  spot: true

叢集自動配置器在比較不同 Spot VM 類型的費用時，可能會以 us-central1 的定價資料做為基準，因此在其他區域可能會做出看似不理想的選擇。這是已知行為。

評估結果

Spot VM 設定正確：如果指定 spot: true 欄位，且叢集自動配置器佈建 Spot VM，則設定會正常運作。
無法排定 Spot VM 的時程：
- 解讀：需要 Spot VM 的 Pod 可能無法排程至 Spot VM，原因可能是目標可用區的資源不足，或是叢集自動配置器根據 us-central1 定價模式選擇了其他 VM 類型。
- 解決方法：
  - 如果您懷疑資源無法使用，請參閱「檢查資源是否無法使用」。
  - 如要控管 Spot VM 的選取作業，請在 priorities 欄位中，依區域從最便宜到最貴，明確列出 machineType 項目。這種做法可讓您直接控制備用廣告順序。例如：
```
spec:
  priorities:
  - machineType: t2d-standard-48 # Cheapest in this region
    spot: true
  - machineType: n2d-standard-48 # Fallback Spot option
    spot: true
  - machineType: n2d-standard-48 # On-demand fallback
    spot: false
```

叢集自動配置器的一般健康狀態

本節說明如何檢查可能與自訂 ComputeClass 設定無直接關聯，但會影響其運作的問題。

檢查是否有並行作業

確認沒有其他叢集或節點集區作業同時進行。GKE 對並行作業設有限制，這可能會阻礙自動調度資源。

列出不在 DONE 狀態的進行中作業：

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

如果指令傳回任何作業，表示叢集升級、節點集區建立或其他修改等動作可能正在進行中。這項作業完成前，自動調度資源事件可能會遭到封鎖。

評估結果

沒有並行作業：如果 list 指令傳回空白清單，表示叢集自動配置器未遭到任何作業封鎖。
發現並行作業：
- 解讀：如果指令列出的作業狀態為 RUNNING 或 PENDING，表示可能有並行作業 (例如叢集升級或節點集區修改) 正在進行，導致自動調度資源功能無法運作。
- 解決方法：等待進行中的作業完成。您可以使用作業 ID 監控狀態，方法如下：
```
gcloud container operations wait OPERATION_ID --location LOCATION
```
  將 OPERATION_ID 替換為 list 指令輸出內容中的 ID。封鎖作業完成後，叢集自動配置器應會恢復正常運作。

查看進行中的遷移作業

如果發現高優先順序節點可用時，工作負載仍留在低優先順序節點上，請確認是否已啟用主動遷移功能。如果 ComputeClass 的 activeMigration.optimizeRulePriority 欄位設為 false 或省略，GKE 就不會在優先順序較高的節點可用時，自動將工作負載移至這些節點。

如要檢查 Pod 容忍度，請查看 spec.tolerations 欄位。如果 Pod 的容許度與多個不同優先順序的節點集區上的汙染相符，排程器可能會將 Pod 放在優先順序較低的節點上 (如果該節點先可用)。
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
```
如要確認是否已啟用主動遷移功能，請檢查 ComputeClass 資訊清單中的 spec.activeMigration.optimizeRulePriority 欄位。
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

評估結果

啟用主動遷移：如果 activeMigration.optimizeRulePriority 欄位為 true，GKE 會在優先順序較高的節點可用時，嘗試將工作負載移至這些節點。
主動遷移功能已停用或無效：
- 解讀：如果 activeMigration.optimizeRulePriority 欄位為 false 或省略，或者 Pod 容忍度過於寬鬆，則當有更高優先順序的節點可用時，工作負載仍會保留在較低優先順序的節點上。這種做法可讓工作負載排定在優先順序較低、但最先可用的節點上。
- 解決方法：如要將工作負載移至優先順序較高的節點，請執行下列任一操作：
  - 使用更具體的排程限制，例如nodeAffinity，優先使用優先順序較高的節點集區。
  - 編輯 ComputeClass 資訊清單來設定 activeMigration.optimizeRulePriority: true，並套用 YAML 檔案：
```
spec:
  activeMigration:
    optimizeRulePriority: true
```

取得支援

如果說明文件無法解決您的問題，請參閱「取得支援」一文，瞭解如何取得進一步協助，包括下列主題的建議：
- 與 Cloud Customer Care 聯絡，建立客服案件。
- 在 StackOverflow 提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。您也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
- 使用公開 Issue Tracker 提出問題或功能要求。

排解自訂 ComputeClass 問題 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

基本概念

依症狀排解問題

超出範圍的問題

找出預留位置變數

事前準備

執行基本診斷檢查

驗證 Pod 狀態和選取器

評估結果

確認叢集版本相容性

評估結果

驗證為自訂 ComputeClass 佈建的節點

驗證自訂 ComputeClass 設定

檢查 ComputeClass 健康狀態和狀態

評估結果

驗證 unsatisfiable 政策

評估結果

檢查 Pod 排程限制

驗證廣告連播資源要求

評估結果

檢查是否有衝突的污點和容許

評估結果

分析叢集自動配置器待處理 Pod 指標

查詢步驟

PromQL 查詢範例

指標原因

分析節點佈建失敗情形

解讀失敗原因

節點集區設定 (Standard 叢集)

驗證節點集區標籤和 taint

評估結果

驗證節點集區自動建立設定

確認已啟用節點集區自動建立功能

評估結果

檢查節點集區自動建立功能的資源限制

評估結果

分析自動配置器備用行為

檢查資源是否無法使用

評估結果

驗證專案配額

評估結果

進階設定

驗證 GPU 設定

評估結果

驗證 Spot VM 設定

評估結果

叢集自動配置器的一般健康狀態

檢查是否有並行作業

評估結果

查看進行中的遷移作業

評估結果

取得支援

後續步驟

排解自訂 ComputeClass 問題

驗證 `unsatisfiable` 政策