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

排解自訂 ComputeClass 問題

Autopilot Standard

本文可協助您排解問題，例如 GKE 工作負載無法在自訂 ComputeClass 定義的節點上排程，或是叢集自動調度器未佈建預期的機型。

本文適用於應用程式開發人員，以及使用自訂 ComputeClasses 管理 GKE 中工作負載排程和節點集區自動建立作業的平台管理員和運算子。如要進一步瞭解 Google Cloud 內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。

基本概念

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

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

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

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

超出範圍的問題

本文不討論下列問題：

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

找出預留位置變數

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

變數	說明
`PROJECT_ID`	您的 Google Cloud 專案 ID。
`LOCATION`	叢集所在的 Compute Engine 區域或可用區。
`CLUSTER_NAME`	叢集名稱。
`NODE_POOL_NAME`	要檢查的節點集區名稱 (適用於標準叢集)。
`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 佈建的節點屬性相容。

驗證廣告連播資源要求

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

取得 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
```

檢查是否有衝突的 taint 和容許條件

為自訂 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
```

節點集區設定 (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 清單中的下一個規則。GKE 會立即改用下一個優先順序，不會等待，但如果使用 TPU 或彈性啟動佈建模式，則可設定延遲時間。

檢查資源是否無法使用

檢查叢集自動配置器記錄或 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 名稱，然後前往「錯誤」分頁標籤。尋找指出資源耗盡的訊息。

使用 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，請確認 ComputeClass 資訊清單中的 spot: true 設定位於正確的優先順序規則中。此外，請務必瞭解叢集自動調度程式的定價邏輯。

檢查 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 排程限制

驗證廣告連播資源要求

評估結果

檢查是否有衝突的 taint 和容許條件

評估結果

節點集區設定 (Standard 叢集)

驗證節點集區標籤和 taint

評估結果

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

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

評估結果

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

評估結果

分析自動配置器備用行為

檢查資源是否無法使用

評估結果

驗證專案配額

評估結果

進階設定

驗證 GPU 設定

評估結果

確認 Spot VM 設定

評估結果

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

檢查是否有並行作業

評估結果

查看進行中的遷移作業

評估結果

取得支援

後續步驟

排解自訂 ComputeClass 問題

驗證 `unsatisfiable` 政策