AI 向けに最適化された GKE クラスタを管理する

このページでは、A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 GPU）マシンの AI 最適化 Google Kubernetes Engine（GKE）クラスタを管理する方法について説明します。これには、GKE クラスタと AI ワークロードに関連する次の一般的なイベントが含まれます。

  • ホスト メンテナンス
  • クラスタのアップグレード
  • 障害のあるホストの報告

AI ワークロードのホスト メンテナンスを管理する

GKE ノードは Compute Engine インスタンスで実行されます。このインスタンスでは、AI ワークロードに影響を与える可能性のあるホストイベントが定期的に 発生します。ホストイベントは基盤となる Google Cloud インフラストラクチャで発生するため、GKE のメンテナンスの時間枠と除外をバイパスします。 ほとんどのコンピューティング インスタンスでは、ホスト メンテナンス ポリシーがライブ マイグレーションに設定されているため、ワークロードの中断は最小限に抑えられますが、GPU と TPU は ライブ マイグレーションをサポートしていません。 これらのホストイベントが AI ワークロードを実行している GKE ノードに影響する場合、GKE はノードとノードで実行されている Pod を終了する必要があります。Pod が Job や Deploymentなどのより大きなワークロードの一部としてデプロイされている場合、 GKE は、影響を受けるノードの Pod を再起動しようとします。

基盤となるコンピューティング インスタンスのホスト メンテナンスの管理の詳細については、 GPU と TPU の GKE ノードの停止を管理するをご覧ください。

ホスト メンテナンス イベントをモニタリングする

GKE バージョン 1.31.1-gke.2008000 以降を実行しているクラスタでは、ホスト メンテナンス イベントのスケジュールされた開始時間を次の方法で確認できます。開始時間は、すべての GPU と TPU の対応する GKE ノードの Kubernetes ノードラベルで表されます。

詳細については、メンテナンス通知をモニタリングする をご覧ください。

これらのノードラベルを使用すると、次のことができます。

ホスト メンテナンス イベントを手動で開始する

Compute Engine からスケジュールされたメンテナンス イベントに関する通知が発行されたら、スケジュールに合わせてメンテナンスを手動で開始できます。たとえば、アクティビティが低下している期間にメンテナンスを実施できます。

ホスト メンテナンス イベントを手動で開始しない場合、スケジュールされたメンテナンスが定期的に Compute Engine によって自動的に実施されます。

ホスト メンテナンス イベントを手動で開始するの手順に沿って操作します。また、このセクションを読み進めて、次のことを確認してください。

ワークロードのスケジュール時にホスト メンテナンス情報を使用する

GKE ノード ラベルを通じて公開されるメンテナンス情報を、ノード アフィニティと アンチアフィニティ とともに使用して、ワークロードの中断を最小限に抑えることができます。

この情報の使用方法の例については、次のセクションをご覧ください。

今後のメンテナンス イベントがスケジュールされていないノードに Pod をスケジュールする

今後のメンテナンス イベントがスケジュールされていないノードにのみ Pod をスケジュールするように GKE に指示できます。たとえば、次のスニペットを使用します。

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

特定の日付以降にメンテナンスがスケジュールされているノードに Pod をスケジュールする

Unix エポック時間を指定することで、特定の日付以降にメンテナンスがスケジュールされているノードにのみ Pod をスケジュールするように GKE に指示できます。

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

AI ワークロードの GKE クラスタのアップグレードを管理する

AI ワークロードは中断の影響を受けやすいものです。

GKE クラスタのライフサイクル中、AI ワークロードは、基盤となるコンピューティング インスタンスと GKE クラスタ自体の中断に備える必要があります。

クラスタをリリース チャンネルに登録しておくことをおすすめします。 デフォルトでは、GKE クラスタは Regular リリース チャンネルに登録されます。リリース チャンネルのメリットの詳細については、 リリース チャンネルに登録されているクラスタと登録されていないクラスタの比較 をご覧ください。

リリース チャンネルを使用すると、メンテナンス除外スコープの追加など、より多くの機能にアクセスできます。 メンテナンス除外 スコープ。 AI ワークロードには「マイナー アップグレードまたはノード アップグレードなし」スコープをおすすめします。

GKE を使用して障害のあるホストを報告する

このセクションでは、GKE を使用して、予約バインド プロビジョニング モデルを使用してプロビジョニングされたコンピューティング インスタンスを持つ障害のある ホストを報告する方法について説明します。 flex-start プロビジョニング モデル (プレビュー) を使用してプロビジョニングされたノードの障害のあるホストを報告する場合は、 アカウント チームにお問い合わせください。

ノードで GPU メモリまたは Xid エラーが発生し、ホストに障害があると報告する前に、 ゲスト OS の再起動（kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true）をトリガーするなどの手動復旧措置で問題を解決できるかどうかを確認する場合は、Xid メッセージを確認するをご覧ください。

ホストは、データセンター内の単一の物理サーバー マシンで、GKE ノードをホストするコンピューティングインスタンスを実行します。障害のあるホストを報告するには、影響を受ける GKE ノードに fault-behavior ノードラベルを適用します。特定の GKE ノードにノードラベルを適用すると、GKE は次の手順を行います。

  1. ノードからワークロードを正常に強制排除します。
  2. そのノードで新しい Pod が起動されなくなります。
  3. コンピューティング インスタンスで API を呼び出して、ホストに障害があることをマークします。
  4. コンピューティング インスタンスが正常なホストマシンで再起動されるまで待ちます。予約オペレーション モードとして予約の すべての容量を使用する場合、 修復オペレーションが完了すると、Compute Engine は同じノードでコンピューティング インスタンスを再起動します。
  5. ノードから taint と fault-behavior ラベルを削除します。

その後、ノードはワークロードを再び処理できるようになります。

要件

障害のあるホストを報告するには、GKE ノードが次の要件を満たしている必要があります。

ホストの不具合を報告する

障害のあるホストを報告する手順は次のとおりです。

  1. GKE のオブザーバビリティ ツール、独自のモニタリング ツール、またはログを使用して、パフォーマンスの問題が発生している GKE ノードを特定します。NODE_NAME を保存します。

  2. 次のコマンドを使用して、ノードに障害があると報告します。理由を指定できます。新しいバージョンでは、説明を指定できます。

      kubectl patch node NODE_NAME --type merge -p '{
    "metadata": {
      "labels": {
        "cloud.google.com/fault-behavior": "FAULT_REASON"
      },
      "annotations": {
        "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
      }
    }
  }'

    コマンドを次のように変更します。

    • NODE_NAME を障害のある ノードの名前に置き換えます。
    • FAULT_REASON を適切な障害 理由に置き換えます。次のいずれか 1 つ以上の値を使用します。
      • PERFORMANCE: コンピューティング インスタンスの GPU のパフォーマンスがクラスタ内の他の GPU よりも遅く、ログに XID エラーが表示されず、サイレント データ破損などの他の一般的な障害パターンが検出されない場合は、この値を使用します。
      • SDC: データ破損が発生しているが、システム クラッシュが発生していない場合は、サイレント データ破損にこの値を使用します。このデータ破損は、CPU の不良、use-after-free やメモリの破損などのソフトウェア バグ、カーネルの問題、その他の不良が原因で発生することがあります。通常、この用語 はハードウェアに起因する不良を指します。
      • XID: コンピューティング インスタンスで XID を使用して修復不可能な GPU エラー を特定した場合は、この値を使用します。
      • unspecified: コンピューティング インスタンスの問題の原因となっている動作が不明な場合は、この値を使用します。これがデフォルト 値です。ただし、該当する場合は、他のいずれかの値を指定することをおすすめします。
      • GKE クラスタのコントロール プレーンのバージョンに基づいて annotations ブロックを調整します。
      • 1.35.6-gke.1017000 以降、または 1.36.0-gke.3251000 以降: annotations ブロックを保持し、 FAULT_DESCRIPTION を観測された障害のテキスト説明に置き換えます。これには、XID エラーコード、 症状、タイムスタンプを含めることができます。この説明は、修復診断を支援するために Compute Engine に転送され、オペレーションが完了するとノードから自動的に削除されます。 例: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z。
      • 以前のバージョン: コマンドから annotations ブロック全体を削除します。これらのバージョンでは、fault-description フィールドは Compute Engine に転送されず、ノードから自動的に削除されません。代わりに、アカウント チームまたは Cloud カスタマーケアに連絡して、障害の詳細をお知らせください。
ノードの障害のあるホストを報告した後、ノードが再起動するタイミングは、 ノードが使用する予約で指定された 予約オペレーションモードによって異なります。 予約の運用モードを確認するには、 予約の reservationOperationalModeフィールドを表示します。 次の表に、使用可能な 2 つの予約オペレーション モード（すべての容量モードとマネージド モード）の障害のあるホストのプロセスをまとめます。
すべての容量モード（ALL_CAPACITY） マネージド モード（HIGHLY_AVAILABLE_CAPACITY）
サポートされているマシンタイプ A4X Max と A4X A4、A3 Ultra、A3 Mega、A3 High
Faulty host report API のレート制限 レート制限は適用されません。 API の呼び出しにはレート制限が適用される場合があります。
障害のあるホストの報告プロセス

すべての容量モードで実行されているノードの障害のあるホストを報告すると、次のようになります:

  1. Pod を強制排除する: ラベルが障害のあるノードに適用されると、GKE ノードを taint して 新しい Pod のスケジュール設定をブロックします。また、GKE はノードで実行中の Pod の正常な強制排除を開始します。GKE は、Pod マニフェストの PodDisruptionBudget（PDB）と spec.terminationGracePeriodSeconds フィールドを尊重します。詳細については、 ワークロードを正常に終了するように GKE を構成するをご覧ください。
  2. 障害のあるホストを報告して修復する: GKE は、Compute Engine API を呼び出して、障害のあるホストを自動的に報告して修復します。これにより、通常 10 ～ 12 分で障害のあるホストを報告し、ホストの修復に 3 ～ 14 日、場合によってはそれ以上かかる一連のオペレーションが発生します。

  3. インスタンスを再起動する: ホストの修復オペレーションが完了すると（通常 3 ～ 14 日）、次のいずれかが発生します。

    • インスタンスが REPAIRING 状態にあり、修復が完了したときにリソースが使用可能な場合、Compute Engine は修復されたホストでインスタンスを自動的に再起動します。
    • それ以外の場合、インスタンスが TERMINATED 状態にある場合、または修復が完了したときにリソース が使用できない場合、インスタンスの状態は TERMINATED のままになるか、 TERMINATED に変わります。インスタンスを実行する場合は、インスタンスを手動で再起動する必要があります。ただし、インスタンスの再起動時にリソースが使用できない場合（修復されたホストを他のインスタンスがすでに使用している場合など）、インスタンスの再起動が失敗することがあります。

マネージド モードで実行されているノードの障害のあるホストを報告すると、 次のようになります。

  1. Pod を強制排除する: ラベルが障害のあるノードに適用されると、GKE ノードを taint して 新しい Pod のスケジュール設定をブロックします。また、GKE はノードで実行中の Pod の正常な強制排除を開始します。GKE は、Pod マニフェストの PodDisruptionBudget（PDB）と spec.terminationGracePeriodSeconds フィールドを尊重します。詳細については、 ワークロードを正常に終了するように GKE を構成するをご覧ください。
  2. 障害のあるホストを報告して修復を開始する: GKE は、Compute Engine API を呼び出して、障害のあるホストを自動的に報告して修復します。これにより、通常 10 ～ 12 分で障害のあるホストを報告し、ホストの修復に 3 ～ 14 日、場合によってはそれ以上かかる一連のオペレーションが発生します。

  3. インスタンスを移行して再起動する: ホストの修復オペレーションが開始されると（通常は 10 ～ 12 分）、Compute Engine は、予約済み容量で報告された障害のあるホストを置き換えるために、別のホストを予約しようとします。Compute Engine が正常なホストを見つけた場合（障害のあるホストの置き換えに成功した場合や、予約済み容量で一致する正常なホストを見つけた場合など）、Compute Engine はインスタンスをそのホストに移行します。その後、次のいずれかの方法でインスタンスが再起動されます。

    • インスタンスが REPAIRING 状態にあり、修復が完了する前または完了時にリソースが使用可能な場合、Compute Engine は正常なホストでインスタンスを自動的に再起動します。
    • それ以外の場合、インスタンスが TERMINATED 状態にある場合、または修復が完了する前または完了時にリソース が使用できない場合、インスタンスの状態は TERMINATED のままになるか、TERMINATED に変わります。インスタンスを実行する場合は、インスタンスを 手動で再起動する 必要があります。ただし、インスタンスの再起動時にリソースが使用できない場合（修復されたホストを他のインスタンスがすでに使用している場合など）、インスタンスの再起動が失敗することがあります。

オペレーションの進行状況をモニタリングする

GKE のオペレーションの進行状況は、GKE ノードの cloud.google.com/report-and-replace-status ノードラベルを使用してモニタリングできます。このラベルには次のいずれかの値が設定されます。

  • PodsEvicted: GKE は、影響を受けるノードからの Pod の強制排除を完了しました。
  • OperationRUNNING: 障害のあるホストを報告するオペレーションが実行されています。
  • OperationDONE: 基盤となるホストに障害があると報告され、GKE ノードを新しいホストに移動する準備ができました。
  • OperationFAILED: 割り当て上限やその他のインフラストラクチャの問題により、コンピューティング インスタンスの API が失敗しました。エラーの詳細については、 障害のあるホストの報告 API エラーのトラブルシューティングをご覧ください。 復旧方法については、 報告と置換の失敗を処理するをご覧ください。
  • Error：リクエストが前の セクションで説明した 要件のいずれかを満たしていないため、API 呼び出しが失敗しました。

node.gke.io/report-and-replace-operation ノードラベルを表示して、Compute Engine オペレーション ID を表示し、オペレーションのステータスをモニタリングすることもできます。

次のコマンドを使用して、これらのノードラベルの両方を表示できます。

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation

API エラーが発生すると、GKE は cloud.google.com/report-and-replace-status ノードラベルを Error に設定します。オペレーションが失敗すると、GKE はラベルを OperationFAILED に設定します。 どちらの場合も、GKE は cloud.google.com/fault-behavior ノードラベルを削除します。また、GKE バージョン 1.35.6-gke.1256000 以降、または 1.36.0-gke.4060000 以降では、GKE はノードに cloud.google.com/report-and-replace-failed:NoSchedule taint を適用します。この taint により、新しい Pod がノードでスケジュールされなくなり、ワークロードがホストに障害がある可能性のあるノードに配置されないようにします。詳細については、 報告と置換の失敗を処理するをご覧ください。

障害のあるホストの報告オペレーションの詳細なステータスを追跡する方法については、障害のあるホストの報告オペレーションを確認するをご覧ください。

報告と置換の失敗を処理する

報告と置換のオペレーションが失敗すると、GKE は影響を受けるノードに cloud.google.com/report-and-replace-failed:NoSchedule taint を適用します。この taint により、基盤となるホストに障害がある可能性がある間、新しいワークロードがノードにスケジュールされないように、ノードが隔離されます。

失敗の taint を確認する

ノードに報告と置換の失敗の taint があるかどうかを確認するには、次のコマンドを実行します。

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

報告と置換の失敗から復旧する

報告と置換の失敗から復旧するには、次のいずれかを行います。

  • ノードに cloud.google.com/fault-behavior ラベルを再適用して、オペレーションを再試行 します。再試行が成功すると、GKE は cloud.google.com/report-and-replace-failed:NoSchedule taint を自動的に削除します。

      kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON

  • ノードが正常であると判断した場合、またはノードをサービスに戻す場合は、taint を手動で削除 します。

      kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-

次のステップ