GKE での GPU のトラブルシューティング

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

GPU ドライバのインストール

このセクションでは、GKE での NVIDIA デバイス ドライバの自動インストールに関するトラブルシューティング情報を提供します。

Ubuntu ノードでドライバのインストールが失敗する

L4 GPU、H100 GPU、または H200 GPU がアタッチされた Ubuntu ノードを使用する場合、GKE がインストールするデフォルトの GPU ドライバが、これらの GPU に必要なバージョン以上ではない可能性があります。その結果、GPU デバイス プラグイン Pod が保留中のままになり、これらのノード上の GPU ワークロードで問題が発生する可能性があります。

L4 GPU と H100 GPU でこの問題を解決するには、GPU ドライバ バージョン 535 をデフォルト ドライバとしてインストールする次の GKE バージョンにアップグレードすることをおすすめします。

  • 1.26.15-gke.1483000 以降
  • 1.27.15-gke.1039000 以降
  • 1.28.11-gke.1044000 以降
  • 1.29.6-gke.1073000 以降
  • 1.30.2-gke.1124000 以降

また、次のコマンドを実行して、ドライバ バージョン 535 以降を手動でインストールすることもできます。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml

H200 GPU でこの問題を解決するには、次のコマンドを実行して、ドライバ バージョン 550 以降を手動でインストールする必要があります。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml

GPU デバイス プラグインが CrashLoopBackOff エラーで失敗する

2023 年 1 月 25 日より前にノードプールでドライバの手動インストール方法を使用した場合、その後、ドライバの自動インストールをサポートする GKE バージョンにノードプールをアップグレードすると、次の問題が発生します。両方のインストール ワークロードが同時に存在し、競合するドライバ バージョンをノードにインストールしようとします。

GPU デバイス プラグイン init コンテナが Init:CrashLoopBackOff ステータスで失敗します。コンテナのログは次のようになります。

failed to verify installation: failed to verify GPU driver installation: exit status 18

この問題を解決するには、次の方法を試してください。

  • 手動ドライバ インストール DaemonSet をクラスタから削除します。これにより、競合するインストール ワークロードが削除され、GKE がノードにドライバを自動的にインストールできるようになります。

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • 手動ドライバ インストール DaemonSet マニフェストをクラスタに再適用します。2023 年 1 月 25 日に、自動ドライバのインストールを使用するノードを無視するようにマニフェストを更新しました。

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • ノードプールの自動ドライバのインストールを無効にします。更新オペレーションが完了すると、既存のドライバ インストール DaemonSet が正常に動作するようになります。

    gcloud container node-pools update POOL_NAME \
    --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION

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

    • POOL_NAME: ノードプールの名前。
    • GPU_TYPE: ノードプールですでに使用されている GPU タイプ。
    • GPU_COUNT: ノードプールにすでに接続されている GPU の数。
    • CLUSTER_NAME: ノードプールを含む GKE クラスタの名前。
    • LOCATION: クラスタの Compute Engine のロケーション。

エラー: "Container image cos-nvidia-installer:fixed is not present with pull policy of Never." または "Container image ubuntu-nvidia-installer:fixed is not present with pull policy of Never."

この問題は、nvidia-driver-installer Pod が PodInitializing 状態にあり、GPU プラグイン デバイスまたは GPU ドライバ インストーラ Pod が次のエラーを報告している場合に発生します。具体的なエラー メッセージは、ノードで実行されているオペレーティング システムによって異なります。

COS

Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.

Ubuntu

Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.

この問題は、ガベージ コレクタがプリロードの NVIDIA ドライバ イメージを削除してノードのスペースを解放するときに発生することがあります。ドライバ Pod が再作成された場合、またはそのコンテナが再起動された場合、GKE はプリロードされたイメージを見つけることができません。

COS の実行時に発生するガベージ コレクションの問題を軽減するには、修正を含む次のいずれかのバージョンに GKE ノードをアップグレードします。

  • 1.25.15-gke.1040000 以降
  • 1.26.10-gke.1030000 以降
  • 1.27.6-gke.1513000 以降
  • 1.28.3-gke.1061000 以降

ノードで Ubuntu を実行している場合、このガベージ コレクションの問題に対する修正はまだありません。Ubuntu でこの問題を軽減するには、ホストとやり取りする特権コンテナを実行して、NVIDIA GPU ドライバが正しく設定されるようにします。この操作を行うには、ノードから sudo /usr/local/bin/nvidia-container-first-boot を実行するか、次のマニフェストを適用します。

apiVersion: v1
kind: Pod
metadata:
  name: gke-nvidia-installer-fixup
spec:
  nodeSelector:
    cloud.google.com/gke-os-distribution: ubuntu
  hostPID: true
  containers:
  - name: installer
    image: ubuntu
    securityContext:
      privileged: true
    command:
      - nsenter
      - -at
      - '1'
      - --
      - sh
      - -c
      - "/usr/local/bin/nvidia-container-first-boot"
  restartPolicy: Never

この問題の別の原因として、ノードの再起動またはホストのメンテナンス後に NVIDIA ドライバ イメージが失われることも考えられます。これは、エフェメラル ローカル SSD ストレージを使用する機密ノード、または GPU を使用するノードで発生する可能性があります。この場合、GKE はノードに nvidia-installer-driver コンテナ イメージをプリロードし、これらのイメージを初回起動時にブートディスクからローカル SSD に移動します。

ホスト メンテナンス イベントがあったことを確認するには、次のログフィルタを使用します。

resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")

ホストのメンテナンスの問題を軽減するには、GKE バージョンを次のいずれかのバージョンにアップグレードします。

  • 1.27.13-gke.1166000 以降
  • 1.29.3-gke.1227000 以降
  • 1.28.8-gke.1171000 以降

エラー: failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

NCCL fastsocket が有効になっている場合、GPU デバイス プラグイン内の GPU ドライバ インストーラ コンテナでこのエラーが発生します。

failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

この問題は、GKE 1.28 と 1.29 を実行しているクラスタおよびノードでのみ発生します。

この問題は、GPU ドライバ インストーラと NCCL fastsocket の競合状態が原因で発生します。

この問題を軽減するには、GKE バージョンを次のいずれかのバージョンにアップグレードします。

  • 1.28.8-gke.1206000 以降
  • 1.29.3-gke.1344000 以降

詳細については、GPUDirect-TCPXO リリースノートをご覧ください。

エラー: Failed to get device for nvidia0: device nvidia0 not found.

次のエラーは、マイナー 0 の GPU で XID 62 と RmInitAdapter が失敗したことを示しています。

Failed to get device for nvidia0: device nvidia0 not found.

NVIDIA ドライバ バージョン 525.105.17 には通信エラー（XID）を引き起こすバグがあり、これにより、GPU が正しく初期化されない可能性があります。

この問題を解決するには、NVIDIA ドライバをドライバ バージョン 525.110.11 以降にアップグレードします。

A3 VM で GPU をリセットする

問題によっては、A3 VM で GPU をリセットする必要があります。

GPU をリセットする手順は次のとおりです。

  1. GPU をリセットする必要があるノードから、GPU リソースをリクエストする Pod を削除します。

  2. ノードで GPU デバイス プラグインを無効にします。

    kubectl get nodes \
    --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers | awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true

    NODE_NAME は、ノードの名前で置き換えます。

  3. ノードをバッキングする VM に接続します。

  4. SSH セッションで GPU をリセットします。

    /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset

  5. GPU デバイス プラグインを再度有効にします。

    kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers \| awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \
    --overwrite

Confidential GKE Node の GPU

以下のセクションでは、Confidential GKE Node 上で動作する GPU に関する問題の特定と解決方法を説明します。

GPU ワークロードが Confidential GKE Node にスケジューリングされない

Confidential GKE Node では、選択した GPU タイプと GKE バージョンに対応する GPU ドライバを手動でインストールする必要があります。GPU Pod が Confidential GKE Node でスケジューリングされずに Pending 状態のままになっている場合は、ドライバ インストール DaemonSet を記述します。

kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml

出力で NotFound エラーが返る場合は、ドライバをインストールします。

DaemonSet が実行されている場合、出力は次のようになります。

apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: nvidia-driver-installer
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: nvidia-driver-installer
        name: nvidia-driver-installer
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: Exists
              - key: cloud.google.com/gke-gpu-driver-version
                operator: DoesNotExist
              - key: cloud.google.com/gke-confidential-nodes-instance-type
                operator: In
                values:
                - TDX

この出力で、nodeAffinity フィールドに cloud.google.com/gke-confidential-nodes-instance-type キーが含まれていることを確認します。出力にこのキーが含まれていない場合、そのドライバ インストール用の DaemonSet は Confidential GKE Node をサポートしていません。

Confidential GKE Node 上で GPU をサポートする DaemonSet をデプロイします。

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml

ドライバをインストールしたら、GPU ワークロードが正常に起動するかどうかを確認します。

エラー: デバイス ベクトルの割り当てに失敗しました

GPU コンテナログに次のエラー メッセージが記録されている場合、GPU がノード VM インスタンスから切り離されたことを示しています。

Failed to allocate device vector A (error code unknown error)!

この切り離しは、ハードウェア エラーまたは暗号鍵の問題が原因で発生することがあります。

この問題を解決するには、ノード インスタンスを再起動します。このオペレーションは中断を伴い、そのノード上のすべてのワークロードに影響します。インスタンスを再起動する手順は次のとおりです。

  1. GPU Pod を実行するノードの名前を取得します。

    kubectl get pod POD_NAME -o yaml | grep "nodeName"

    POD_NAME は、失敗した Pod の名前に置き換えます。

    出力は次のようになります。

    nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e

  2. Compute Engine インスタンスをリセットします。

    gcloud compute instances reset NODE_NAME

    NODE_NAME は、前の手順の出力のノード名に置き換えます。

    gcloud CLI は、アクティブなプロジェクトでその名前の VM を探します。ゾーンを選択するプロンプトが表示されたら、Y を指定します。

  3. GPU ワークロードがエラーなく実行されているかどうかを確認します。

エラー: 復号に失敗しました（エラー -74）

ノードログに次のエラー メッセージが記録されている場合は、GPU の暗号鍵が失われたことを示しています。

Decryption failed with error -74

このエラーは、ノード VM インスタンスで実行されている NVIDIA 永続デーモンが失敗した場合に発生します。このエラー メッセージが表示された場合は、インスタンスをリセットします。

gcloud compute instances reset NODE_NAME

NODE_NAME は、失敗したノードの名前に置き換えます。

gcloud CLI は、アクティブなプロジェクトでその名前の VM を探します。ゾーンを選択するプロンプトが表示されたら、Y を指定します。

インスタンスをリセットしてもこの問題が解決しない場合は、Cloud カスタマーケアにお問い合わせいただくか、プロダクト バグを送信してください。詳細については、サポートを利用するをご覧ください。

XID エラーの検出

gpu-device-plugin daemonset は kube-system 名前空間内で実行され、次の処理を行います。

  • GPU ワークロードのスケジューリング: GPU リソースを Pod に割り当てます。
  • GPU のヘルスチェック: GPU の健全性をモニタリングします。
  • GPU 指標の収集: デューティ サイクルやメモリ使用量など、GPU 関連の指標を収集します。

gpu-device-plugin は、NVIDIA Management Library（NVML）を使用して XID エラーを検出します。XID エラーが発生すると、影響を受けるノードで実行されている gpu-device-plugin Pod がエラーをログに記録します。XID エラーログには次の 2 種類があります。

  • 重大でない XID エラー:
    • ログ形式: Skip error Xid=%d as it is not Xid Critical
    • 意味: これらのエラーは重大ではないとみなされます。さまざまなソフトウェアやハードウェアの問題が原因で発生することがあります。
    • 対応: GKE は、重大でない XID エラーに対して自動で対応しません。
  • 重大な XID エラー:
    • ログ形式: XidCriticalError: Xid=%d, All devices will go unhealthy
    • 意味: これらのエラーは、GPU ハードウェアの問題を示します。
    • 対応:
      • GKE は、ノードの GPU リソースを異常としてマークします。
      • GKE は、ノードに GPU ワークロードがスケジュールされないようにします。
      • ノードの自動修復が有効になっている場合、GKE はノードを再作成します。

GPUDirect-TCPX(O) の問題

このセクションでは、GPUDirect-TCPX(O) の問題のトラブルシューティング情報をご案内します。

リリースノートとアップグレード手順

新規ユーザーの方向けに、Standard モードのクラスタで GPU ネットワーク帯域幅を最大化するというガイドで、GPUDirect-TCPX(O) の使い方をご案内しています。既存のユーザーの方は、GPUDirect-TCPXO のリリースノートでリリース情報やアップグレード手順をご確認ください（新バージョンが継続的にリリースされているため）。

NCCL ログを使用してデバッグする

NCCL の問題を解決できない場合は、デバッグ情報を含む NCCL ログを収集します。これらのログには NCCL オペレーションに関する貴重な情報が含まれており、問題の原因を特定するのに役立ちます。問題を解決できない場合は、Cloud カスタマーケアでケースをオープンする前に、これらのログを収集してください。これらのログは、Cloud カスタマーケアが問題を迅速に解決するのに役立ちます。

ログを生成して収集する手順は次のとおりです。

  1. Pod またはアプリケーション マニフェスト内に次の環境変数を設定します。

    NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p

    これらの環境変数の詳細については、NCCL のデバッグログを収集するをご覧ください。

  2. ログのデータを生成するには、NCCL テストを実行します。このテストの実行方法は、使用するクラスタのタイプによって異なります。GKE クラスタの場合は、トポロジを考慮したスケジューリング（TAS）を使って NCCL テストをデプロイおよび実行できます。NCCL テストを実行すると、NCCL は参加するすべてのノードでログを自動的に生成します。

  3. すべてのノードからログを収集します。すべてのノードから NCCL ログが収集できていることを、ログに次の情報が含まれているかどうかで確認してください。

    • ワークロードに関連するすべての VM のホスト名。
    • VM 上の関連するすべてのプロセスの PID。
    • 各 VM のワークロードで使用されるすべての GPU のランク。

    ログファイルの場所がわからない場合は、次の例をご覧ください。NCCL_DEBUG_FILE 変数が /tmp/nccl_log.%h.%p に設定されている場合、NCCL がログファイルを作成する場所を示しています。a3plus-vm-1 と a3plus-vm-2 という名前の 2 つの VM があり、各 VM はワークロード コンテナ内で 8 つのプロセスを実行します。このシナリオでは、NCCL は各 VM のワークロード コンテナ内の /tmp ディレクトリに次のログファイルを作成します。

    • a3plus-vm-1 に対して: nccl_log.a3plus-vm-1.PID という名前の 8 つのログファイル。ここで、PID はプロセス ID です。
    • a3plus-vm-2 に対して: nccl_log.a3plus-vm-2.PID という名前の 8 つのログファイル。

  4. ログを確認します。NCCL ログエントリの形式は次のとおりです。

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    これらのログエントリには、次の値が含まれています。

    • HOSTNAME: VM のホスト名。この値は、NCCL がログエントリを生成するときに使用されていた VM を識別します。
    • PID: PID。この値は、ログエントリを生成したプロセスを識別します。
    • TID: スレッド IDこの値は、NCCL がログエントリを生成するときに使用されていたプロセス内のスレッドを識別します。
    • RANK: ローカルランク ID。この値は、NCCL がログエントリを生成するときに使用されていた GPU を識別します。ランクは 0～N で、N はプロセスに関与する GPU の合計数です。たとえば、ワークロードが VM ごとに 8 つの GPU で実行される場合、各 VM には 8 つの異なるランク値（0～7）が必要です。
    • NCCL_MESSAGE: イベントの詳細情報を提供し、NCCL がログを作成したタイムスタンプを含む説明的なメッセージ。

    例:

    gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.

    この例では、次の値が設定されています。

    • gke-a3plus-mega-np-2-aa33fe53-7wvq: ホスト名
    • 1581: プロセス ID。
    • 1634: スレッド ID
    • 1: ローカルランク ID。
    • NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: 発生した事象を説明するメッセージ。

  5. サポートケースを登録する場合は、収集したログと NCCL テストの出力を ZIP ファイルにパッケージ化します。Cloud カスタマーケアへのサポートケースの提出時に ZIP ファイルを含めます。

  6. NCCL デバッグログの収集を停止するには、手順 1 で追加した変数を削除します。

次のステップ

  • このドキュメントに問題のソリューションが見当たらない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。