排解自訂 ComputeClass 問題

自動駕駛標準

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

本文適用於應用程式開發人員，以及使用自訂 ComputeClass 管理 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 資源設定錯誤，可能會導致 Pod 無法排程，或 GKE 無法正確佈建節點。

檢查 ComputeClass 健康狀態和狀態

確認 GKE 將自訂 ComputeClass 回報為正常。

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

說明特定 ComputeClass 資源：

kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

評估結果

健康狀態顯示 True：自訂 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
```

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

節點集區設定 (標準叢集)

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

驗證節點集區標籤和汙點

找出自訂 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
```

分析自動配置器回退行為

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

自訂 ComputeClass 會使用優先順序較高的備用邏輯。如果 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 與管理) >「配額」。
2. 篩選 Compute Engine API 服務。
3. 查看相關指標的使用量，例如 CPU、GPU (所有類型) 和 GKE 叢集所在區域的已用 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 客戶服務聯絡，建立支援案件。
- 在 StackOverflow 上提問，並使用 google-kubernetes-engine 標記搜尋類似問題，向社群尋求支援。你也可以加入 #kubernetes-engine Slack 頻道，取得更多社群支援。
- 使用公開 Issue Tracker 開啟問題或功能要求。

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

基本概念

依症狀排解問題

超出範圍的問題

找出預留位置變數

事前準備

執行基本診斷檢查

驗證 Pod 狀態和選擇器

評估結果

確認叢集版本是否相容

評估結果

驗證自訂 ComputeClass 設定

檢查 ComputeClass 健康狀態和狀態

評估結果

驗證 unsatisfiable 政策

評估結果

檢查 Pod 排程限制

驗證廣告連播資源要求

評估結果

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

評估結果

節點集區設定 (標準叢集)

驗證節點集區標籤和汙點

評估結果

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

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

評估結果

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

評估結果

分析自動配置器回退行為

檢查資源是否無法使用

評估結果

驗證專案配額

評估結果

進階設定

確認 GPU 設定

評估結果

驗證 Spot VM 設定

評估結果

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

檢查是否有並行作業

評估結果

查看進行中的遷移作業

評估結果

取得支援

後續步驟

排解自訂 ComputeClass 問題

驗證 `unsatisfiable` 政策