このページでは、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状態である必要があります。コンピューティング インスタンスを削除した後に障害のあるホストを報告しようとすると、エラー メッセージが返され、ホストマシンは障害ありとマークされません。 - ブロックの健全性の評価に基づいて、予約ごとに月ごとのこの 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は、次の値の 1 つ以上を使用して、適切な障害理由に置き換えます。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） |
マネージド モード（HIGHLY_AVAILABLE_CAPACITY） |
|
|---|---|---|
| サポートされているマシンタイプ | A4X Max と A4X | A4、A3 Ultra、A3 Mega、A3 High |
| Faulty host report API のレート制限 | レート制限は適用されません。 | API の呼び出しにはレート制限が適用される場合があります。 |
| 障害のあるホストの報告プロセス |
全容量モードで実行されているノードの障害のあるホストを報告すると、次のようになります。
|
マネージド モードで実行されているノードの障害のあるホストを報告すると、次のようになります。
|
オペレーションの進行状況をモニタリングする
GKE ノードの cloud.google.com/report-and-replace-status ノードラベルを使用して、GKE のオペレーションの進行状況をモニタリングできます。このラベルには、次のいずれかの値が設定されます。
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 により、新しい Pod がノードにスケジュールされなくなり、ワークロードが潜在的に障害のあるホストを持つノードに配置されなくなります。詳細については、レポートと置換の失敗を処理するをご覧ください。
障害のあるホストの報告オペレーションの詳細なステータスを追跡する方法については、障害のあるホストの報告オペレーションを確認するをご覧ください。
報告と交換の失敗を処理する
報告と置換のオペレーションが失敗すると、GKE は影響を受けるノードに cloud.google.com/report-and-replace-failed:NoSchedule テイントを適用します。この taint により、基盤となるホストに障害が発生している可能性がある間、ノードが閉鎖された状態になり、新しいワークロードがスケジュールされなくなります。
障害の taint を確認する
ノードに report-and-replace 障害のテイストがあるかどうかを確認するには、次のコマンドを実行します。
kubectl describe node NODE_NAME | grep "report-and-replace-failed"
交換対応の失敗から復元する
レポートと交換の失敗から復元するには、次のいずれかを行います。
ノードに
cloud.google.com/fault-behaviorラベルを再度適用して、オペレーションを再試行します。再試行が成功すると、GKE はcloud.google.com/report-and-replace-failed:NoScheduleテイントを自動的に削除します。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-
次のステップ
障害のあるホスト API エラーのトラブルシューティング方法について学習する。