AI 最適化 Google Kubernetes Engine(GKE)クラスタを作成したら、ノードの健全性予測を有効にできます。トポロジを考慮したスケジューリング(TAS)と Kueue を使用してワークロードをスケジュールする場合は、ノードの健全性予測を有効にすると、クラスタのスケジューラで次の操作を行うことができます。
今後 5 時間以内にパフォーマンスが低下する可能性のあるノードを特定します。
これらのノードで新しいワークロードのスケジュール設定を回避します。
このアプローチは、大規模なトレーニング ワークロードなど、中断に敏感な重要なワークロードの中断を最小限に抑えるのに役立ちます。
このドキュメントでは、汎用 GPU マシンシリーズ(A3 Edge、A2、G2、G4、N1)または クラスタ化 GPU マシンシリーズ(A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High)ノードを使用する GKE クラスタでノードの健全性予測を有効にする方法について説明します。たとえば、Slurm クラスタのパフォーマンスの問題をトラブルシューティングする場合に、Cloud Monitoring ダッシュボードでノードの健全性予測指標を使用する方法については、Compute Engine インスタンスと Slurm クラスタをモニタリングするをご覧ください。
制限事項
GKE クラスタでノードの健全性予測を有効にする前に、次の制限事項を考慮してください。
ノードは、汎用 GPU(A3 Edge、A2、G2、G4、N1)またはクラスタ GPU(A4X Max、A4X、A4、A3 Ultra、A3 Mega、A3 High)マシンタイプを使用する必要があります。
ノードが予約にバインドされたプロビジョニング モデルを使用していること。
ノードの健全性予測について
GKE クラスタでノードの健全性予測を有効にすると、CronJob はクラスタ内の各ノードに gke.google.com/recommended-to-run-large-training-workload ラベルを適用します。CronJob は、ノードの GPU の健全性が低下する可能性をラベル値に設定し、これらの値を 10 分ごとに更新します。ラベル値が true の場合、ノードは正常です。それ以外の場合、ラベル値が false の場合、ノードは 5 時間以内に劣化する可能性があります。ラベル値は、ノードの GPU の健全性に基づいて時間の経過とともに変化する可能性があります。
ノードのパフォーマンスが低下する可能性がある場合は、次のいずれかまたは両方を行うことができます。
ノードでワークロードのスケジュール設定を回避する。このドキュメントで説明するように、値が
falseのノードでワークロードのスケジュール設定を回避するように Kueue を構成できます。ノードに障害があることを報告します。ノードで GPU 温度が高い、パフォーマンスが遅いなどの問題が発生している場合は、ノードを障害として報告できます。このアクションにより、ノードのホスト メンテナンス イベントが開始され、メンテナンスが完了すると、ワークロードの実行に再び使用できるようになります。手順については、GKE を介して障害のあるホストを報告するをご覧ください。
始める前に
作業を始める前に、次のタスクが完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API を有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化します。gcloud CLI をインストール済みの場合は、
gcloud components updateコマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
クラスタに接続するには、次のコマンドを実行します。
gcloud container clusters get-credentials CLUSTER_NAMECLUSTER_NAMEは、使用するクラスタの名前に置き換えます。
ノードの健全性予測を有効にする
TAS を使用して GKE クラスタでワークロードをスケジュールする準備ができたら、次の手順でノードの健全性予測を有効にできます。
ノードの自動ラベル付けをデプロイする
GKE クラスタでノードの健全性予測の自動ノードラベル付けをデプロイするには、次の操作を行います。
GKE git リポジトリでハードウェア アクセラレータのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/container-engine-accelerators.gittopology-schedulerディレクトリに移動します。cd container-engine-accelerators/gpudirect-tcpxo/topology-schedulerヘルススコアをクエリする Python スクリプト
schedule-daemon.pyとlabel-nodes-daemon.pyを含む Kubernetes ConfigMap を作成します。kubectl create configmap predictor-scheduler-scripts \ --namespace=kube-system \ --from-file=schedule-daemon.py=schedule-daemon.py \ --from-file=label-nodes-daemon.py=label-nodes-daemon.pyサービス アカウントの構成を適用して、CronJob に必要な権限(Monitoring 指標の読み取りと Node オブジェクトのパッチ適用)を付与します。
kubectl apply -f service-account.yamlノード ラベリング ジョブのスケジュールを設定する DaemonSet をデプロイします。
kubectl apply -f label-nodes-daemon.yaml
ジョブ構成を更新する
Kueue を使用するときにノードの健全性予測を有効にするには、ワークロードを開始する前に、健全性予測の値と、サポートされている場合はトポロジ要件を確認するように Job 構成を更新する必要があります。
ジョブ構成を更新してノードの健全性予測を有効にするには、spec フィールドに次のフィールドを追加します。
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gke.google.com/recommended-to-run-large-training-workload
operator: NotIn
values:
- "False"
...
ノードのラベル付けを確認する
CronJob が初めて実行された後(デプロイから約 10 分後)、ノードに gke.google.com/recommended-to-run-large-training-workload ラベルが適用されているかどうかを確認します。
gke.google.com/recommended-to-run-large-training-workload ラベルが適用されているノードのリストを表示します。
kubectl get nodes -L gke.google.com/recommended-to-run-large-training-workload
ラベル値は次のいずれかになります。
true: ノードは次の 5 時間で正常になると予測されます。false: ノードが 5 時間以内に劣化する可能性が高い。このドキュメントで説明したように Job 構成を構成した場合、Kueue はノードで新しいワークロードのスケジューリングを回避します。
次のステップ
GKE クラスタと AI ワークロードに関連する一般的なイベントの管理については、AI 最適化 GKE クラスタを管理するをご覧ください。
Kueue を使用して GKE でジョブをスケジュールする方法については、Kueue を使用してバッチシステムをデプロイするをご覧ください。