このページでは、AI 最適化された Google Kubernetes Engine（GKE）クラスタの A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High（8 個の GPU）マシンを管理する方法について説明します。これには、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 プロビジョニング モデル（プレビュー）を使用してプロビジョニングされたノードの障害のあるホストを報告する場合は、アカウント チームにお問い合わせください。
ホストは、データセンター内の単一の物理サーバーマシンであり、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 label nodes NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON次のように置き換えます。
NODE_NAME: 障害のあるノードの名前。FAULT_REASON: 次の 1 つ以上の値を使用して、適切な障害理由を指定します。PERFORMANCE: コンピューティング インスタンスの GPU のパフォーマンスがクラスタ内の他の GPU よりも遅く、ログに XID エラーが表示されず、サイレント データ破損などの他の一般的な障害パターンが検出されない場合は、この値を使用します。SDC: データ破損は確認できるものの、システム クラッシュは発生していない場合は、サイレント データ破損にこの値を使用します。このデータ破損は、CPU の不良、use-after-free やメモリの踏みつけなどのソフトウェアのバグ、カーネルの問題、その他の不良が原因で発生することがあります。この用語は、ハードウェアに起因する欠陥を指す場合によく使用されます。XID: コンピューティング インスタンスの XID で修復不可能な GPU エラーを特定した場合は、この値を使用します。unspecified: コンピューティング インスタンスで問題が発生している原因が不明な場合は、この値を使用します。これがデフォルト値です。ただし、該当する場合は、他のいずれかの値を指定することをおすすめします。
reservationOperationalMode フィールドを表示します。次の表に、利用可能な 2 つの予約運用モード（すべての容量モードとマネージド モード）の障害のあるホストプロセスをまとめます。All Capacity モード（ALL_CAPACITY） |
マネージド モード（HIGHLY_AVAILABLE_CAPACITY） |
|
|---|---|---|
| サポートされているマシンタイプ | A4X Max と A4X | A4、A3 Ultra、A3 Mega、A3 High |
| Faulty host report API のレート制限 | レート制限は適用されません。 | API の呼び出しにはレート制限が適用される場合があります。 |
| 障害のあるホストの報告プロセス |
All Capacity モードで実行されているノードの障害のあるホストを報告すると、次のようになります。
|
マネージド モードで実行されているノードの障害のあるホストを報告すると、次のようになります。
|
オペレーションの進行状況をモニタリングする
GKE ノードの cloud.google.com/report-and-replace-status ノードラベルを使用して、GKE のオペレーションの進行状況をモニタリングできます。このラベルには、次のいずれかの値が設定されます。
PodsEvicted: GKE は、影響を受けるノードから Pod の強制排除を完了しました。OperationRUNNING: 障害のあるホストを報告するオペレーションが実行中です。OperationDone: 基盤となるホストに障害が発生したことが報告され、GKE ノードを新しいホストに移動する準備が整っているError: API 呼び出しが失敗しました。原因は、前のセクションで説明した要件のいずれかなどです。
cloud.google.com/report-and-replace-operation ノードラベルを表示して、Compute Engine オペレーション ID を表示し、オペレーションのステータスをモニタリングすることもできます。
次のコマンドを使用すると、これらのノードラベルの両方を表示できます。
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 ラベルをノードに再適用します。
次のステップ
障害のあるホスト API エラーのトラブルシューティング方法を確認する。