カスタム ComputeClass の問題のトラブルシューティング

Autopilot Standard

このドキュメントは、GKE ワークロードがカスタム ComputeClass で定義されたノードにスケジュールできない場合や、クラスタ オートスケーラーが想定されるマシンタイプをプロビジョニングしない場合の問題のトラブルシューティングに役立ちます。

このドキュメントは、カスタム ComputeClass を使用して GKE でワークロードのスケジューリングとノードプールの自動作成を管理するアプリケーション デベロッパー、プラットフォーム管理者、運用担当者を対象としています。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

注: このドキュメントは、Standard クラスタと Autopilot クラスタの両方に適用されます。Autopilot クラスタでは SSH などのノードへの直接アクセスがサポートされていないため、これらの環境に合わせてトラブルシューティングの手順を調整する必要があります。

主なコンセプト

トラブルシューティングを行うには、次の GKE コンポーネントとメカニズムを理解しておく必要があります。

• カスタム ComputeClass: 自動スケーリング用のノード構成の優先順位付きリストを定義できる GKE 固有のリソース。詳細については、カスタム ComputeClass についてをご覧ください。

• クラスタ オートスケーラー: ワークロードの需要に基づいてクラスタ内のノードを自動的に追加または削除するコンポーネント。詳細については、 GKE クラスタの自動スケーリングについてをご覧ください。

• ノードプールの自動作成: GKE クラスタ オートスケーラーは、ワークロードの要件に基づいてノードプールを自動的に作成して管理します。詳細については、ノードプールの自動作成についてをご覧ください。

• フォールバック ロジック: クラスタ オートスケーラーが、優先度が最も高いルールに一致するノードを最初にプロビジョニングしようとするメカニズム。詳細については、フォールバックのコンピューティングの優先度を選択するをご覧ください。

問題の内容別のトラブルシューティング

このドキュメントでは、基本的なチェックから高度な構成まで、トラブルシューティングの手順を順に説明します。より包括的な診断を行うには、次の手順を順番に行うことをおすすめします。または、特定の問題が発生している場合は、次の表の該当するリンクを参照してください。

症状	トラブルシューティング手順
カスタム ComputeClass をリクエストする Pod が Pending 状態で停止する	基本的な診断チェックを実施する Pod のスケジューリング制約を確認する ノードプールの構成（Standard クラスタの場合）
クラスタ オートスケーラーがカスタム ComputeClass に一致する新しいノードを作成しない	カスタム ComputeClass の構成を確認する ノードプールの自動作成構成を確認する
クラスタ オートスケーラーが特殊なタイプではなくデフォルトのマシンタイプを作成する	オートスケーラーのフォールバック動作を分析する
kubectl describe computeclass コマンドの出力に異常なステータスが表示される	カスタム ComputeClass の構成を確認する
ワークロードが優先度の高いノードに移行しない	クラスタ オートスケーラーの一般的な健全性を確認する
GPU または Spot VM のワークロードでスケジューリングの問題が発生する	Pod のスケジューリング制約を確認する GPU VM または Spot VM の構成を確認する オートスケーラーのフォールバック動作を分析する

サポート範囲外の問題

このドキュメントでは、次の問題については説明しません。

• Pod 間接続やサービス ロード バランシングなど、一般的な GKE ネットワーキングの問題。
• HorizontalPodAutoscaler（HPA）または VerticalPodAutoscaler（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 の Namespace。
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 を正しくリクエストしていることを確認します。

1. Pending 状態の Pod を一覧表示します。

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

2. 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 を正常と報告していることを確認します。

1. すべての ComputeClass リソースを一覧表示します。

   kubectl get computeclass
   

2. 特定の 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 フィールドの値を指定しておらず、1.33 より前の GKE バージョンを使用している場合、ポリシーはデフォルトで 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 のリソース リクエストを確認する

Pod の CPU、メモリ、GPU のリクエストが、カスタム ComputeClass の priorities フィールドで定義されたマシンタイプの少なくとも 1 つで満たされるかどうかを確認します。

1. Pod のリソース リクエストを取得します。

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

   出力で、cpu、memory、GPU リクエスト（nvidia.com/gpu など）を確認します。

2. これらのリクエストを、カスタム ComputeClass の priorities フィールドで定義されているマシンタイプと比較します。

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
       -o jsonpath='{.spec.priorities}'
   

   出力で machineType フィールドまたは machineFamily フィールドを確認します。カスタム ComputeClass の各マシンタイプについて、マシンタイプのドキュメントで仕様を確認し、割り当て可能なリソースが Pod のリクエストよりも大きいかどうかを確認します。

結果を評価する

• 互換性のあるリソース: Pod のリソース リクエストが、ComputeClass の少なくとも 1 つのマシンタイプで割り当て可能なリソース以下である。

• リソースが容量を超えている:

  • 解釈: ComputeClass のどのマシンタイプも十分な CPU、メモリ、GPU を提供していないため、Pod をスケジュールできません。これは、nodePoolAutoCreation フィールドが true に設定され、Pod のメモリ リクエストが自動作成されたノードプールの制限を超えた場合にも発生する可能性があります。
  • 解決策: Pod のリソース リクエストまたはカスタム ComputeClass のマシンタイプを調整します。
    • Pod のリソース リクエストを減らす: リソース リクエストが高い場合は、ワークロードの YAML ファイルで cpu、memory、または gpu の値を下げます。
    • より大きなマシンタイプに変更する: Pod のリクエストが正当な場合は、カスタム ComputeClass マニフェストの spec.priorities フィールドを変更して、Pod の要求を満たすことができるより大きな machineType オプションまたは machineFamily オプションを含めます。次に例を示します。

  spec:
    priorities:
    - machineType: n2d-highmem-96 # A larger machine type
      spot: true
    # ... other priorities
  

競合する taint と toleration を確認する

カスタム ComputeClass 用に作成されたノードには cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule テイントがあります。GKE は、この toleration を Pod に自動的に追加します。

ただし、GPU などの特殊なハードウェアには、nvidia.com/gpu=present:NoSchedule taint などの taint が追加されています。ComputeClass が特殊なハードウェアを備えたノードを使用している場合、これらのノードでスケジュールするには、Pod にこれらの taint の toleration が必要です。

Pod の tolerations フィールドを確認します。

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

結果を評価する

• 正しい toleration: taint と toleration が正しく構成されています。

• 欠落している容認:

  • 解釈: 容認機能がないため、Pod は専用ハードウェア taint を持つノードでスケジュールできません。たとえば、ComputeClass で GPU ノードを使用している場合、Pod に nvidia.com/gpu=present:NoSchedule 許容範囲がない可能性があります。GPU 固有の要件については、GPU 構成を確認するをご覧ください。

  • 解決策: Pod 仕様の tolerations フィールドで、ComputeClass で定義されたノードの taint に一致する必要な toleration を追加します。たとえば、GPU ノードの場合は、次のように nvidia.com/gpu=present:NoSchedule taint の toleration を追加します。

    spec:
    template:
    spec:
    tolerations:
    - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
    # ... other tolerations and Pod spec
    

ノードプールの構成（Standard クラスタ）

GKE Standard クラスタでは、カスタム ComputeClass で動作するように、手動で作成したノードプールにラベルと taint を設定する必要があります。

ノードプールのラベルと taint を確認する

1. カスタム ComputeClass でノードプールを特定します。カスタム ComputeClass が nodePools フィールドを使用している場合は、リストされているノードプールの名前をメモします。

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

2. 特定したノードプールごとに、構成を確認します。

   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 と taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule が設定されています。

• ノードプールの構成が誤っている:

  • 解釈: ノードプールは、カスタム ComputeClass に関連付けるために必要なラベルと taint で構成されていません。

  • 解決策: ノードプールを更新して、ラベルと taint を追加します。

    1. ノードラベルを追加または更新します。

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

    2. ノードの taint を追加または更新します。

       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 クラスタの両方で、ノードプールの自動作成が正しく構成されている必要があります。

ノードプールの自動作成が有効になっていることを確認する

1. カスタム ComputeClass の nodePoolAutoCreation.enabled フィールドが true に設定されているかどうかを確認します。

   kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
   

2. クラスタでノードプールの自動作成が有効になっているかどうかを確認します。

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

いずれかが無効になっている場合、ノードプールの自動作成ではカスタム ComputeClass の新しいノードプールは作成されません。

結果を評価する

• ノードプールの自動作成が有効: ComputeClass で、nodePoolAutoCreation.enabled フィールドが true に設定され、クラスタレベルでノードの自動プロビジョニングが有効になっています。

• ノードプールの自動作成が無効:

  • 解釈: ComputeClass の nodePoolAutoCreation.enabled フィールドの値が false であるか、ComputeClass に nodePoolAutoCreation.enabled フィールドがない場合、またはクラスタレベルのノード自動プロビジョニングが無効になっている場合、ノードプールの自動作成は無効になります。

  • 解決策: ノードプールの自動作成を有効にします。

    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 とメモリのクラスタ全体の上限があります。クラスタの現在の使用量と新しいノードのリソースの合計がこれらの上限を超えると、ノードプールの自動作成によって新しいノードがプロビジョニングされません。

1. リソースの上限を表示します。

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

   出力には、CPU とメモリの resourceType、minimum、maximum フィールドが一覧表示されます（単位は GB）。

2. カスタム ComputeClass の優先度でマシンタイプを確認します。CPU とメモリの仕様については、マシンタイプのドキュメントをご覧ください。

3. クラスタ内のすべてのノードの現在の合計 CPU 容量とメモリ容量を特定します。現在の容量と新しいノードのリソースの合計が、ノードプールの自動作成の上限を超えないようにする必要があります。

結果を評価する

• 十分な容量: クラスタには、ノードプールの自動作成で新しいノードをプロビジョニングするのに十分な CPU とメモリ容量がリソース上限内にあります。

• 上限を超過しました:

  • 解釈: クラスタが CPU またはメモリの上限に達したか、ComputeClass のマシンタイプの上限が低すぎるため、ノードプールの自動作成で新しいノードをプロビジョニングできません。

  • 解決策: ノードプールの自動作成のリソース上限を増やします。

    1. カスタム ComputeClass の最大マシンタイプを含め、現在の使用量と将来の増加を考慮した新しい上限を決定します。

    2. ノードプールの自動作成のリソース上限を更新する。1 つのコマンドで複数のリソースを設定できます。

       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 リストの次のルールをすぐに試します。GKE が次の優先度にフォールバックするまでの待機期間はありません。ただし、TPU または Flex Start プロビジョニング モデルを使用する場合は、構成可能な遅延がサポートされます。

リソースの利用不可を確認する

クラスタ オートスケーラーのログまたは Compute Engine マネージド インスタンス グループ（MIG）のエラーを確認して、指定されたゾーンでリソースが使用できないかどうかを確認します。

オプション 1: クラスタ オートスケーラーの公開設定イベントを確認する

Google Cloud コンソールで、[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.resource.exhausted"

オプション 2: MIG エラーを確認する

MIG エラーは、 Google Cloud コンソールまたは Cloud Logging クエリを使用して確認できます。

• Google Cloud コンソールを使用する場合:

  1. Google Cloud コンソールで、[Compute Engine] > [インスタンス グループ] に移動します。
  2. スケールアップに失敗したノードプールに対応する MIG を見つけます。
  3. MIG 名をクリックして、[エラー] タブに移動します。リソースの枯渇を示すメッセージを探します。

• Cloud Logging クエリの使用:

  1. Google Cloud コンソールで、[Cloud Logging] > [ログ エクスプローラ] に移動します。
  2. 次のクエリを実行して、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 アドレスなどのリソースに対する十分な割り当てがあることを確認します。

1. オートスケーラーのログで割り当てエラーを確認します。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
   

2. Google Cloud コンソールで割り当てを確認します。

   1. Google Cloud コンソールで、[IAM と管理 > 割り当て] に移動します。
   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 容認があることを確認します。

1. カスタム 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
   

2. Pod で GPU の容認を検査します。GPU ノードでスケジュールする必要がある Pod は、Pod 自体が GPU をリクエストしていない場合でも、nvidia.com/gpu toleration を持つ必要があります。

   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 容認が欠落している、GPU フィールドの不一致が原因で ComputeClass が異常である、または 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 は、ターゲット ゾーンでリソースが使用できないため、またはクラスタ オートスケーラーが us-central1 料金モデルに基づいて別の VM タイプを選択しているため、Spot 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 では一度に 1 つのオペレーションしか許可されないため、自動スケーリングがブロックされる可能性があります。

DONE 状態ではない進行中のオペレーションを一覧表示します。

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

コマンドがオペレーションを返した場合は、クラスタのアップグレード、ノードプールの作成、その他の変更などのアクションが進行中である可能性があります。このオペレーションが完了するまで、自動スケーリング イベントがブロックされることがあります。

結果を評価する

• 同時実行オペレーションなし: list コマンドが空のリストを返した場合、クラスタ オートスケーラーはオペレーションによってブロックされません。

• Concurrent operations found:

  • 解釈: コマンドでステータスが RUNNING または PENDING のオペレーションが一覧表示された場合、クラスタのアップグレードやノードプールの変更などの同時オペレーションが進行中で、自動スケーリングがブロックされている可能性があります。

  • 解決策: 進行中のオペレーションが完了するまで待ちます。オペレーション ID を使用してステータスをモニタリングするには、次の操作を行います。

    gcloud container operations wait OPERATION_ID --location LOCATION
    

    OPERATION_ID は、list コマンドの出力の ID に置き換えます。ブロック オペレーションが完了すると、クラスタ オートスケーラーは通常の機能を再開します。

アクティブな移行を確認する

優先度の高いノードが使用可能なときに、ワークロードが優先度の低いノードに残っている場合は、アクティブな移行が有効になっているかどうかを確認します。ComputeClass で activeMigration.optimizeRulePriority フィールドが false に設定されているか、省略されている場合、GKE は優先度の高いノードが使用可能になっても、ワークロードを自動的に移動しません。

1. Pod の容認を確認するには、spec.tolerations フィールドを確認します。Pod に、優先度の異なる複数のノードプールの taint と一致する toleration がある場合、スケジューラは、優先度の低いノードが最初に使用可能になったときに、そのノードに Pod を配置する可能性があります。

   kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
   

2. アクティブな移行が有効になっているかどうかを確認するには、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 チャネルに参加して、コミュニティ サポートを利用することもできます。
  • 公開バグトラッカーを使用して、問題の報告や機能リクエストの登録を行う。

次のステップ

• デフォルトで ComputeClass を Pod に適用する
• GKE でワークロードの分離を構成する
• クラスタ オートスケーラーのスケールアップに関する問題のトラブルシューティング