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 プロビジョニング モデル (プレビュー) を使用してプロビジョニングされたノードの障害のあるホストを報告する場合は、 アカウント チームにお問い合わせください。

ホストは、データセンター内の単一の物理サーバー マシンで、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 は、 PodDisruptionBudget（PDB）と Pod マニフェストの 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 は、 PodDisruptionBudget（PDB）と Pod マニフェストの 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 ノードを新しいホストに移動する準備ができました。
  • Error：前の セクションで説明した 要件のいずれかなど、API 呼び出しが失敗しました。

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

次のコマンドを使用すると、両方のノードラベルを表示できます。

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

API エラーが発生した場合、GKE はノードラベル cloud.google.com/report-and-replace-status=ERROR を設定します。GKE はノード taint をクリアし、cloud.google.com/fault-behavior ノードラベルを削除します。

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

レート制限などの一時的なエラーに対してオペレーションを再試行するには、ノードに cloud.google.com/fault-behavior ラベルを再度適用します。

次のステップ