このページでは、A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 GPU）マシンの AI 最適化 Google Kubernetes Engine（GKE）クラスタを管理する方法について説明します。これには、GKE クラスタと AI ワークロードに関連する次の一般的なイベントが含まれます。
- ホスト メンテナンス
- クラスタのアップグレード
- 障害のあるホストの報告
AI ワークロードのホスト メンテナンスを管理する
GKE ノードは、AI ワークロードを中断する可能性のあるホストイベントが定期的に発生する Compute Engine インスタンスで実行されます。ホストイベントは基盤となる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 クラスタ自体の両方の中断に備える必要があります。
- ホスト メンテナンス: 基盤となるコンピューティング インスタンスのホスト メンテナンスを管理するには、GPU と TPU の GKE ノードの中断を管理するをご覧ください。これについては、前のセクションでも説明しています。
- クラスタのアップグレード: クラスタのアップグレードによる中断を管理するには、次のツールを使用します。
- メンテナンスの時間枠: 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 は次の手順を実行します。
- ノードからワークロードを正常に強制排除します。
- 新しい Pod がノードでスケジュールされないようにします。
- コンピューティング インスタンスで API を呼び出して、ホストに障害があることをマークします。
- コンピューティング インスタンスが正常なホストマシンで復旧するまで待機します。すべての容量の予約運用モードを使用する予約の場合、Compute Engine は修復オペレーションの完了後に同じノードでコンピューティング インスタンスを復元します。
- ノードから taint と
fault-behaviorラベルを削除します。
その後、ノードはワークロードを再び処理できるようになります。
要件
障害のあるホストを報告するには、GKE ノードが次の要件を満たしている必要があります。
- GKE パッチ バージョン 1.32.3-gke.1057001 以降を実行している必要があります。
- 次のいずれかの GPU マシンタイプを実行している必要があります。A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 GPU）。
- 予約にバインドされているコンピューティング インスタンスで GKE ノードを実行する必要があります。
- GKE ノードが
RUNNING状態である必要があります。コンピューティング インスタンスを削除した後に障害のあるホストを報告しようとすると、エラー メッセージが返され、ホストマシンは障害ありとしてマークされません。 - ブロックの健全性の評価に基づいて、予約ごとに 1 か月あたりのこの API の呼び出し回数にレート制限が適用される場合があります。予約ですべての容量の予約運用モードを使用している場合、レート制限は適用されません。
障害のあるホストを報告する
障害のあるホストを報告するには:
GKE オブザーバビリティ ツール、独自のモニタリング ツール、またはログを使用して、パフォーマンスの問題が発生している GKE ノードを特定します。
NODE_NAMEを保存します。次のコマンドを使用して、ノードに障害があることを報告します。理由を指定できます。また、以降のバージョンでは説明を指定できます。
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は、次のいずれかの値を使用して、適切な障害理由に置き換えます。PERFORMANCE: コンピューティング インスタンスの GPU のパフォーマンスがクラスタ内の他の GPU よりも低く、ログに XID エラーが表示されず、サイレント データ破損などの他の一般的な障害パターンが検出されない場合は、この値を使用します。SDC: サイレント データ破損の場合は、この値を使用します。データ破損が発生しているものの、システム クラッシュは発生していない場合です。このデータ破損は、CPU の不良、ソフトウェアのバグ（解放後使用やメモリ ストンピングなど）、カーネルの問題、その他の不具合が原因で発生することがあります。ほとんどの場合、この用語はハードウェアに起因する不具合を指すために使用されます。XID: コンピューティング インスタンスの XID で修復不可能な GPU エラーを特定した場合は、この値を使用します。unspecified: コンピューティング インスタンスの問題の原因となっている動作が不明な場合は、この値を使用します。これがデフォルト値です。ただし、該当する場合は、他の値のいずれかを指定することをおすすめします。
- GKE クラスタのコントロール プレーンのバージョンに基づいて
annotationsブロックを調整します。- 1.35.6-gke.1017000 以降、または 1.36.0-gke.3251000 以降: アノテーション ブロックを保持し、
FAULT_DESCRIPTIONを、観察された障害のテキスト説明に置き換えます。これには、XID エラーコード、症状、タイムスタンプなどが含まれます。この説明は、修復診断を支援するために Compute Engine に転送され、オペレーションの完了後にノードから自動的に削除されます。例:GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z - 以前のバージョン: コマンドから
annotationsブロック全体を削除します。これらのバージョンでは、fault-descriptionフィールドは Compute Engine に転送されず、ノードから自動的に削除されません。代わりに、アカウント チームまたは Cloud カスタマーケアに連絡して、障害の詳細を提供してください。
- 1.35.6-gke.1017000 以降、または 1.36.0-gke.3251000 以降: アノテーション ブロックを保持し、
reservationOperationalMode フィールドを表示します。次の表に、2 つの予約運用モード（All Capacity モードとマネージド モード）の障害のあるホストのプロセスをまとめます。All Capacity モード（ALL_CAPACITY） |
マネージド モード（HIGHLY_AVAILABLE_CAPACITY） |
|
|---|---|---|
| サポートされているマシンタイプ | A4X Max と A4X | A4、A3 Ultra、A3 Mega、A3 High（8 個の GPU） |
| Faulty host report API のレート制限 | レート制限は適用されません。 | API 呼び出しにはレート制限が適用される場合があります。 |
| 障害のあるホストの報告プロセス |
All Capacity モードで実行されているノードの障害のあるホストを報告すると、次のようになります。
|
マネージド モードで実行されているノードの障害のあるホストを報告すると、次のようになります。
|
オペレーションの進行状況をモニタリングする
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 を確認する
ノードに report-and-replace 障害 taint があるかどうかを確認するには、次のコマンドを実行します。
kubectl describe node NODE_NAME | grep "report-and-replace-failed"
報告と交換の失敗から復旧する
レポートと置換の失敗から復元するには、次のいずれかを行います。
ノードに
cloud.google.com/fault-behaviorラベルを再適用して、オペレーションを再試行します。再試行が成功すると、GKE はcloud.google.com/report-and-replace-failed:NoScheduletaint を自動的に削除します。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-