このページの情報の一部またはすべては、S3NS の Trusted Cloud には適用されない場合があります。

GPU と TPU の GKE ノードの中断を管理する

Autopilot Standard

長時間実行される GKE クラスタのライフサイクル中には、Trusted Cloud by S3NS で発生するインフラストラクチャの中断によってワークロードが定期的に中断されます。このような自動イベントは、スケジューリングの決定（プリエンプションイベント）、コントロールプレーンまたはノードの更新（GKE ノードの自動アップグレード（メンテナンスイベント）を含む）、検出された問題の修復（終了イベント）に対応するために発生する可能性があります。

このページでは、GKE でのノード停止の意味、メンテナンス通知のモニタリング方法、GPU と TPU がアタッチされた GKE ノードで停止の影響を最小限に抑える方法について説明します。

このドキュメントは、基盤となる技術インフラストラクチャのライフサイクルを管理するプラットフォームの管理者とオペレーターを対象としています。 Trusted Cloud by S3NS のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

GKE でインフラストラクチャの中断が意味すること

GKE クラスタは、GKE ノードのライフサイクルを管理します。GKE ノードがプロビジョニングされる Compute Engine VM では、次のような中断が定期的に発生します。

検出された問題の修復（TerminationEvent）: Trusted Cloud by S3NS が問題を検出してクラスタインフラストラクチャを中断した場合に発生します。TerminationEvent イベントは正常なシャットダウンに対応していません。TerminationEvent イベントは次の問題によってトリガーされます。
- 自動修復: ヘルスチェックが繰り返し失敗した後で GKE がノードを修復するときに発生します。
- HostError: 物理マシンのハードウェアまたはソフトウェアのエラーが原因で VM が停止したときに発生します。
注: 基盤となる Compute Engine のメンテナンスイベントは自動メンテナンスイベントと見なされます。このようなイベントは、GKE のメンテナンスポリシーと除外をバイパスします。
メンテナンスまたはアップグレードイベント（MaintenanceEvent）: Trusted Cloud by S3NS がメンテナンスを実行するために VM を中断する必要がある場合に発生します。MaintenanceEvent イベントは、次のメンテナンスタスクによってトリガーされます。
- メンテナンスイベント: Trusted Cloud by S3NS が基盤となるホストをアップグレードするときに発生します。
- ノードの更新（ノードの自動アップグレードを含む）: ノードで実行されている Kubernetes のバージョンを GKE が更新するときに発生します。
クラスタのライフサイクル中にユーザーと GKE が変更を管理する方法については、変更の種類をご覧ください。
スケジューリングの決定への応答（PreemptionEvent）:Trusted Cloud by S3NS が優先度の高いリソースの容量を確保するために VM をプリエンプトする必要がある場合に発生します。PreemptionEvent イベントは次のいずれかです。
- 削除: 優先度の高い VM を収容するためにプリエンプティブルまたは Spot インフラストラクチャがプリエンプトされたときに発生します。
- デフラグ: GKE が TPU スライスを収容する目的でそれより小さい TPU スライスをプリエンプトしたときに発生します。デフラグは TPU スライスでのみ行われます。

長時間実行される GKE クラスタのライフサイクル中には、ノードでトレーニングワークロードまたはサービングワークロードの定期的な中断が発生する可能性があります。このような中断が AI / ML ワークロードを実行している GKE ノードに影響する場合、GKE は実行中のワークロードとその基盤となるノードの両方を再起動する必要があります。

GPU と TPU で中断管理が必要となる理由

一部の例外を除き、ほとんどの Compute Engine VM のホストメンテナンスポリシーはライブマイグレーションに設定されています。つまり、実行中のワークロードで停止が生じることはほとんどありません。ただし、特定のクラスの VM はライブマイグレーションに対応していません。これには GPU や TPU がアタッチされた VM も含まれます。すべてのメンテナンスイベントはスライスレベルで調整されるため、TPU スライス内の VM でホストイベントが発生すると、スライス全体が中断されてから再スケジュールされます。そのため、数百台の VM を含む TPU スライスを作成すると、そのすべての VM が同じメンテナンスイベントスケジュールを受け取ります。

ホストイベントが発生すると、GKE はノードとその Pod を終了させます。Pod が Job や Deployment などのより大きなワークロードの一部としてデプロイされている場合、GKE は、影響を受けるノードの Pod を再起動します。

メンテナンスイベントに適切に対応するようにワークロード構成を処理する責任は、ユーザー自身（あるいは使用するフレームワーク）にあります。たとえば、AI トレーニングジョブの状態を保存することでデータの損失を減らせます。

AI / ML ワークロードでの停止を管理するため、次のことを行えます。

ノードとノードプールの中断をモニタリングする
メンテナンス通知をモニタリングする
停止の影響を最小限に抑える

ノードの中断をモニタリングする

次の GKE システム指標は、最後のサンプリング以降の GKE ノードの中断回数を報告します（この指標は 60 秒ごとにサンプリングされます）。

kubernetes.io/node/interruption_count

interruption_type（TerminationEvent、MaintenanceEvent、PreemptionEvent など）フィールドと interruption_reason（HostError、Eviction、AutoRepair など）フィールドは、ノードが中断された理由を把握するのに役立ちます。

プロジェクトのクラスタ内の TPU ノードで発生した中断とその原因の内訳を取得するには、次の PromQL クエリを使用します。

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

ホストメンテナンスイベントのみを表示するには、interruption_reason の HW/SW Maintenance 値をフィルタするようにクエリを更新します。次の PromQL クエリを使用します。

```promql
sum by (interruption_type,interruption_reason)(
  sum_over_time(
kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))
```

ノードプールごとに集計された中断回数を表示するには、次の PromQL クエリを使用します。

```promql
sum by (node_pool_name,interruption_type,interruption_reason)(
  sum_over_time(
    kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))
```

メンテナンス通知をモニタリングする

Compute Engine では、中断を伴うホストイベントがノードとその基盤となる VM でスケジュールされたときと有効になったときに、通知が出されます。通知には、予定されている開始時刻やイベントの種類などの情報が含まれます。

GKE バージョン 1.31.1-gke.2008000 以降では、このセクションで説明するイベントを含む今後のメンテナンスイベントをモニタリングできます。

今後のメンテナンスがスケジュールされているが、有効になっていない

GPU または TPU がアタッチされている VM でメンテナンスイベントがスケジュールされると、Compute Engine からすべての VM に通知が送信され、メンテナンスの時間枠の開始時刻が報告されます。今後のメンテナンスが VM によってスケジュールされたが有効になっていない場合、GKE はノードラベルに scheduled-maintenance-time を追加します。

これらの通知をノードレベルでクエリするには、次のコマンドを実行します。

kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

出力は次のようになります。

NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

SCHEDULED-MAINTENANCE-TIME 列は秒を表し、Unix エポック時間の形式で表示されます。

これらの通知をノードメタデータのレベルでクエリするには、インスタンスでメンテナンスイベント通知を確認します。

スケジュールされたメンテナンスの開始

高度なメンテナンスに対応するアクセラレータ最適化マシンファミリーでは、スケジュールされたメンテナンスイベントと開始されたメンテナンスイベントに関する情報を提供する upcoming-maintenance エンドポイントにアクセスできます。

スケジュールされたメンテナンスが開始すると、Compute Engine で http://metadata.google.internal/computeMetadata/v1/instance/attributes/ ディレクトリ内のメタデータが更新され、メタデータラベルが次のように更新されます。

maintenance-event が TERMINATE_ON_HOST_MAINTENANCE に設定されます。
upcoming-maintenance で、maintenance_status が ONGOING に設定されます。

GKE は、メンテナンス通知の時間枠に含まれる事前定義された最大時間内に、Pod を正常に強制排除してワークロードを終了します。

停止の影響を最小限に抑える

ノードの停止の影響を最小限に抑えるには、ホストメンテナンスイベントを手動で開始します。

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

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

スケジュールされたメンテナンスイベントに関する通知が Compute Engine から出されたとき、ユーザーは運用スケジュールに適したタイミング（アクティビティが減少する期間など）に手動でメンテナンスを開始できます。

ノードプール内のノードで、ノードラベル cloud.google.com/perform-maintenance を true に設定してください。次に例を示します。

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

perform-maintenance アクションによってメンテナンスイベントが開始する前に、GKE は Pod を正常に強制排除してワークロードを終了します。このラベルが適用されてからメンテナンスが開始するまでの期間は、場合によって異なります。

ワークロードを正常に終了するように GKE を構成する

このセクションでは、アプリケーションのライフサイクルを管理し、ワークロードの中断を最小限に抑えるように GKE を構成します。猶予期間を構成しない場合、猶予期間はデフォルトで 30 秒になります。

GKE はベストエフォートでこれらの Pod を正常に終了し、ユーザーが定義した終了アクション（トレーニング状態の保存など）を実行します。また、猶予期間の開始時に Pod に SIGTERM シグナルを送信します。猶予期間の終了までに Pod が終了しなかった場合、GKE は Pod 内のコンテナでまだ実行中のプロセスにフォローアップの SIGKILL シグナルを送信します。

正常終了期間を構成するには、Pod マニフェストの spec.terminationGracePeriodSeconds フィールドで終了猶予期間（秒単位）を設定します。たとえば、通知時間を 10 分にするには、次のように Pod マニフェストの spec.terminationGracePeriodSeconds フィールドを 600 秒に設定します。

    spec:
      terminationGracePeriodSeconds: 600

進行中のタスクが通知期間内に完了できるように、終了猶予期間には十分な時間を設定することをおすすめします。ワークロードで Orbax を使用して MaxText、Pax、JAX などの ML フレームワークを利用している場合、ワークロードはシャットダウンの SIGTERM シグナルをキャプチャして、チェックポイントプロセスを開始できます。詳細については、TPU の Autocheckpoint をご覧ください。

正常終了のプロセス

停止を伴うイベントが開始すると（手動でトリガーされたか、VM によって自動的にトリガーされたかに関係なく）、マシンのシャットダウンが迫っていることを示すために Compute Engine で maintenance-event メタデータキーが更新されます。ノードのシャットダウンが迫ると、GKE は正常終了を開始します。

次のワークフローは、ノードのシャットダウンが迫ったときに、GKE がノードの正常終了を実行する方法を示しています。

60 秒以内に、次の処理が行われます。
1. ワークロードがこれから停止されることを示すため、システムコンポーネントが cloud.google.com/active-node-maintenance ノードラベル（ONGOING に設定済み）を適用します。
2. 新しい Pod がノードでスケジュールされないよう、GKE がノード taint を適用します。この taint には cloud.google.com/impending-node-termination:NoSchedule キーがあります。突然の終了ではないため、この taint を許容するようにワークロードを変更することはおすすめしません。
maintenance-handler コンポーネントが Pod の強制排除を開始します。ワークロード Pod が強制排除されてから、システム Pod（kube-system など）が強制排除されます。
シャットダウンが迫っていることを通知するため、ノードで実行されているワークロード Pod に GKE が SIGTERM シャットダウンシグナルを送信します。このアラートにより、Pod は進行中のタスクを完了できます。GKE は、ベストエフォートでこれらの Pod を正常に停止します。
強制排除が完了すると、GKE は cloud.google.com/active-node-maintenance ラベルの値を terminating に更新し、ノードの終了の準備ができたことを示します。

その後、ノードが終了されて交換ノードが割り当てられます。プロセスが完了すると、GKE はこのラベルと taint をクリアします。GPU または TPU を使用するワークロードの終了時間枠を長くするには、ホストメンテナンスイベントを手動で開始するの説明に従って操作してください。

アクティブな正常終了の進行状況をモニタリングする

次の正常終了イベントによって GKE ログをフィルタできます。

ノードの終了（Compute Engine のホストメンテナンスイベントなど）が迫ったことによる中断を VM が検出すると、GKE はワークロードの停止時に cloud.google.com/active-node-maintenance を ONGOING に設定し、ワークロードが完了してノードが終了の準備が整ったときに terminating に設定します。
新しいワークロードのスケジューリングを制限する際、GKE は cloud.google.com/impending-node-termination:NoSchedule taint を適用します。