GKE で TPU のトラブルシューティングを行う

このページでは、Google Kubernetes Engine（GKE）の TPU に関連する問題を解決する方法について説明します。

TPU リクエストに対応できる十分な割り当てがない

Insufficient quota to satisfy the request のようなエラーは、リクエストを満たすのに十分な割り当てが Google Cloud プロジェクトにないことを示します。

この問題を解決するには、プロジェクトの割り当ての上限と現在の使用量を確認します。必要に応じて、TPU 割り当ての増加をリクエストしてください。

割り当ての上限と現在の使用量を確認する

TPU の割り当ての上限と現在の使用状況を確認する手順は次のとおりです。

  1. Google Cloud コンソールで [割り当て] ページに移動します。

    [割り当て] に移動

  2. [ フィルタ] ボックスで次の操作を行います。

    1. [サービス] プロパティを選択し、「Compute Engine API」と入力して Enter キーを押します。

    2. [割り当て] プロパティを選択し、TPU のバージョンとマシンタイプに基づいて割り当ての名前を入力します。たとえば、マシンタイプが「ct5lp-」で始まるオンデマンド TPU v5e ノードを作成する場合は、「TPU v5 Lite PodSlice chips」と入力します。

      TPU バージョン 次で始まるマシンタイプ オンデマンド インスタンスの割り当て名 Spot VM1インスタンスの割り当ての名前 予約済み2インスタンスの割り当ての名前
      TPU v4 ct4p- TPU v4 PodSlice chips Preemptible TPU v4 PodSlice chips Committed TPU v4 PodSlice chips
      TPU v5e ct5l- TPU v5 Lite Device chips Preemptible TPU v5 Lite Device chips Committed TPU v5 Lite Device chips
      TPU v5e ct5lp- TPU v5 Lite PodSlice chips Preemptible TPU v5 Lite PodSlice chips Committed TPU v5 Lite PodSlice chips

    3. （省略可）高度なフィルタを適用して結果を絞り込むには、項目（ロケーションなど）プロパティを選択し、GKE で TPU を作成するリージョンの名前を追加して、Enter キーを押します。たとえば、ゾーン us-west4-a で TPU v5e ノードを作成する場合は、「region:us-west4」と入力します。

入力したフィルタに一致する割り当てがない場合、プロジェクトには指定された割り当てのいずれも付与されていないため、TPU 割り当ての増加をリクエストする必要があります。

  1. Spot VM インスタンスは、TPU ノードプールの作成時に --spot フラグを使用して作成します。↩

  2. 予約済みインスタンスは、TPU ノードプールの作成時に --reservation フラグを使用して作成します。TPU の予約は、コミットメントを購入した場合に利用できます。↩

TPU 割り当ての引き上げをリクエストする

GKE で TPU ノードを作成するために追加の割り当てが必要な場合は、Google Cloud アカウント担当者に連絡して TPU 割り当ての増加をリクエストしてください。GKE でプロビジョニングされた TPU は、Compute Engine API の数量に基づく割り当てを使用します。GKE で TPU を使用する場合、Cloud TPU API 割り当てに対してリクエストされた割り当ては適用されません。

TPU ノードプールでノードの自動プロビジョニングを有効にする際のエラー

TPU をサポートしていない GKE クラスタでノードの自動プロビジョニングを有効にすると、次のエラーが発生します。

次のようなエラー メッセージが表示されます。

ERROR: (gcloud.container.clusters.create) ResponseError: code=400,
  message=Invalid resource: tpu-v4-podslice.

この問題を解決するには、GKE クラスタをバージョン 1.27.6 以降にアップグレードします。

GKE で TPU ノードが自動的にプロビジョニングされない

以降のセクションでは、GKE が TPU ノードを自動的にプロビジョニングしない場合とその修正方法について説明します。

上限の構成ミス

クラスタに定義した自動プロビジョニングの上限が低すぎる場合、GKE は TPU ノードを自動的にプロビジョニングしません。このようなシナリオでは、次のエラーが発生することがあります。

  • TPU ノードプールが存在しても、リソース上限違反で GKE がノードをスケールアップできない場合、kubectl get events コマンドを実行すると、次のエラー メッセージが表示されます。

    11s Normal NotTriggerScaleUp pod/tpu-workload-65b69f6c95-ccxwz pod didn't
trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 max
cluster cpu, memory limit reached

    また、このシナリオでは、Google Cloud コンソールで次のような警告メッセージが表示されます。

    "Your cluster has one or more unschedulable Pods"

  • リソースの上限を超える TPU ノードプールを GKE が自動プロビジョニングしようとすると、クラスタ オートスケーラーのログに次のエラー メッセージが表示されます。

    messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"

    また、このシナリオでは、Google Cloud コンソールで次のような警告メッセージが表示されます。

    "Can't scale up because node auto-provisioning can't provision a node pool for
the Pod if it would exceed resource limits"

これらの問題を解決するには、クラスタ内の TPU チップ、CPU コア、メモリの最大数を増やします。

手順は次のとおりです。

  1. 特定の TPU マシンタイプのリソース要件と数を計算します。システム ワークロードなど、ノードプールで使用される TPU 以外のリソースを追加する必要があります。

  2. 特定のマシンタイプとゾーンで使用可能な TPU、CPU、メモリの説明を取得します。gcloud CLI を使用します。

    gcloud compute machine-types describe MACHINE_TYPE \
    --zone COMPUTE_ZONE

    次のように置き換えます。

    出力には、次のような説明行が含まれます。

      description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
  ```

  3. CPU とメモリの合計数を計算するには、これらの量に必要なノード数を掛けます。たとえば、ct4p-hightpu-4t マシンタイプは 240 個の CPU コア、407 GB の RAM、4 個の TPU チップを使用します。20 個の TPU チップ（5 つのノードに相当）が必要な場合は、次の値を定義する必要があります。

    • --max-accelerator=type=tpu-v4-podslice,count=20。
    • CPU = 1200（240 × 5）
    • memory = 2035（407 × 5）

    システム ワークロードなどの TPU 以外のノードに対応するには、ある程度の余裕を見て制限を定義する必要があります。

  4. クラスタの上限を更新します。

    gcloud container clusters update CLUSTER_NAME \
    --max-accelerator type=TPU_ACCELERATOR \
    count=MAXIMUM_ACCELERATOR \
    --max-cpu=MAXIMUM_CPU \
    --max-memory=MAXIMUM_MEMORY

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • TPU_ACCELERATOR: TPU アクセラレータの名前。
    • MAXIMUM_ACCELERATOR: クラスタ内の TPU チップの最大数。
    • MAXIMUM_CPU: クラスタの最大コア数。
    • MAXIMUM_MEMORY: クラスタの最大メモリ量（GB）。

ワークロードの構成ミス

このエラーは、ワークロードの構成ミスが原因で発生します。このエラーの最も一般的な原因は次のとおりです。

  • Pod 仕様で cloud.google.com/gke-tpu-accelerator ラベルと cloud.google.com/gke-tpu-topology ラベルが正しくないか、欠落しています。GKE は TPU ノードプールをプロビジョニングせず、ノードの自動プロビジョニングでクラスタをスケールアップできません。
  • Pod 仕様で、リソース要件に google.com/tpu が指定されていません。

この問題を解決するには、以下のいずれかを行います。

  1. ワークロード ノードセレクタに、サポートされていないラベルがないことを確認します。たとえば、cloud.google.com/gke-nodepool ラベルのノードセレクタの場合、GKE は Pod に追加のノードプールを作成できません。
  2. TPU ワークロードが実行される Pod テンプレートの仕様に次の値が含まれていることを確認します。
    • nodeSelector 内の cloud.google.com/gke-tpu-accelerator ラベルと cloud.google.com/gke-tpu-topology ラベル。
    • リクエスト内の google.com/tpu。

TPU ワークロードを GKE にデプロイする方法については、TPU ノードプールで使用可能な TPU チップの数を表示するワークロードを実行するをご覧ください。

TPU を使用する Pod を GKE にデプロイする際のスケジュールに関するエラー

次の問題は、GKE が TPU ノード上の TPU をリクエストする Pod をスケジュールできない場合に発生します。たとえば、TPU 以外の Pod がすでに TPU ノードでスケジュールされている場合に発生することがあります。

Pod で FailedScheduling イベントとして次のようなエラー メッセージが出力されます。

Cannot schedule pods: Preemption is not helpful for scheduling.

Error message: 0/2 nodes are available: 2 node(s) had untolerated taint
{google.com/tpu: present}. preemption: 0/2 nodes are available: 2 Preemption is
not helpful for scheduling

この問題を解決するには、次の操作を行います。

TPU 以外のノードでシステム クリティカルな Pod を実行できるように、クラスタに少なくとも 1 つの CPU ノードプールがあることを確認します。詳細については、Pod を特定のノードプールにデプロイするをご覧ください。

TPU の初期化に失敗した

次の問題は、TPU デバイスへのアクセス権限がないために GKE が新しい TPU ワークロードをプロビジョニングできない場合に発生します。

次のようなエラー メッセージが表示されます。

TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path: "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance

この問題を解決するには、TPU コンテナを特権モードで実行するか、コンテナ内の ulimit を増やします。

スケジューリングのデッドロック

2 つ以上のジョブ スケジューリングがデッドロックにより失敗する場合があります。たとえば、次のすべてが起こりうるシナリオです。

  • Pod アフィニティ ルールを持つ 2 つのジョブ（ジョブ A とジョブ B）があるとします。GKE は、v4-32 の TPU トポロジを使用して、両方のジョブに TPU スライスをスケジュールします。
  • クラスタに v4-32 TPU スライスが 2 つあります。
  • クラスタには、両方のジョブをスケジュールするのに十分な容量があり、理論上は各ジョブを各 TPU スライスで迅速にスケジュールできます。
  • Kubernetes スケジューラは、1 つのスライスでジョブ A から 1 つの Pod をスケジュールし、同じスライスでジョブ B から 1 つの Pod をスケジュールします。

この場合、ジョブ A の Pod アフィニティ ルールに基づいて、スケジューラはジョブ A とジョブ B の残りのすべての Pod を、それぞれ 1 つの TPU スライスでスケジュールしようとします。その結果、GKE はジョブ A またはジョブ B を完全にスケジュールできなくなります。したがって、両方のジョブのステータスは保留中のままになります。

この問題を解決するには、次の例に示すように、cloud.google.com/gke-nodepool を topologyKey として Pod の反アフィニティを使用します。

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 parallelism: 2
 template:
   metadata:
     labels:
       job: pi
   spec:
     affinity:
       podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: In
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: NotIn
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
           namespaceSelector:
             matchExpressions:
             - key: kubernetes.io/metadata.name
               operator: NotIn
               values:
               - kube-system
     containers:
     - name: pi
       image: perl:5.34.0
       command: ["sleep",  "60"]
     restartPolicy: Never
 backoffLimit: 4

us-central2 でクラスタの作成中に権限が拒否される

us-central2（TPU v4 が利用可能な唯一のリージョン）にクラスタを作成しようとすると、次のようなエラー メッセージが表示されることがあります。

ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Permission denied on 'locations/us-central2' (or it may not exist).

このエラーは、リージョン us-central2 が限定公開リージョンであるために発生しています。

この問題を解決するには、サポートケースを送信するか、アカウント チームに連絡して、us-central2 を Google Cloud プロジェクト内で公開するよう依頼してください。

GKE クラスタの作成時にサブネットが見つからない

us-central2（TPU v4 が利用可能な唯一のリージョン）にクラスタを作成しようとすると、次のようなエラー メッセージが表示されることがあります。

ERROR: (gcloud.container.clusters.create) ResponseError: code=404,
message=Not found: project <PROJECT> does not have an auto-mode subnetwork
for network "default" in region <REGION>.

GKE ノードへの接続を提供するには、VPC ネットワークにサブネットが必要です。ただし、us-central2 などの特定のリージョンでは、サブネットを作成するためにデフォルトの VPC ネットワークを自動モードで使用しても、デフォルトのサブネットが作成されないことがあります。

この問題を解決するには、GKE クラスタを作成する前に、リージョンにカスタム サブネットを作成していることを確認します。このサブネットは、同じ VPC ネットワーク内の他のリージョンで作成された他のサブネットと重ならないようにする必要があります。