GKE クラスタでノードの健全性予測を有効にする

AI に最適化された Google Kubernetes Engine（GKE）クラスタを作成したら、ノードの健全性予測を有効にできます。 トポロジを考慮したスケジューリング（TAS）と Kueue を使用してワークロードをスケジュールする場合は、ノードの健全性予測を有効にすると、クラスタのスケジューラは次の処理を行います。

  1. 今後 5 時間以内に劣化する可能性のあるノードを特定する。

  2. これらのノードで新しいワークロードのスケジュール設定を行わない。

このアプローチは、大規模なトレーニング ワークロードなど、中断に敏感な重要なワークロードの中断を最小限に抑えるのに役立ちます。

このドキュメントでは、A4X Max、A4X、A4、A3 Ultra ノードを使用する GKE クラスタでノードの健全性予測を有効にする方法について説明します。たとえば、Slurm クラスタでパフォーマンスの問題をトラブルシューティングする場合に、Cloud Monitoring ダッシュボードでノードの健全性予測指標を使用する方法については、代わりに Compute Engine インスタンスと Slurm クラスタをモニタリングするをご覧ください。

制限事項

GKE クラスタでノードの健全性予測を有効にする前に、次の制限事項を考慮してください。

  • ノードは A4X Max、A4X、A4、A3 Ultra マシンタイプを使用する必要があります。

  • ノードは 予約にバインドされたプロビジョニング モデルを使用する必要があります。

ノードの健全性予測について

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_NAME

    CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

ノードの健全性予測を有効にする

TAS を使用して GKE クラスタでワークロードをスケジュールする準備ができたら、次の手順でノードの健全性予測を有効にできます。

  1. ノードの自動ラベル付けをデプロイする

  2. ジョブ構成を更新する

  3. ノードのラベル付けを確認する

ノードの自動ラベル付けをデプロイする

GKE クラスタでノードの健全性予測のノードの自動ラベル付けをデプロイするには、次の操作を行います。

  1. GKE git リポジトリでハードウェア アクセラレータのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/container-engine-accelerators.git

  2. topology-scheduler ディレクトリに移動します。

    cd container-engine-accelerators/gpudirect-tcpxo/topology-scheduler

  3. 健全性スコアをクエリする 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

  4. サービス アカウント構成を適用して、CronJob に必要な権限（Monitoring 指標の読み取りと Node オブジェクトのパッチ適用）を付与します。

    kubectl apply -f service-account.yaml

  5. ノードのラベル付けジョブをスケジュールする DaemonSet をデプロイします。

    kubectl apply -f label-nodes-daemon.yaml

ジョブ構成を更新する

Kueue を使用するときにノードの健全性予測を有効にするには、ワークロードを開始する前に健全性予測値とトポロジ要件（サポートされている場合）を確認するようにジョブ構成を更新する必要があります。

ジョブ構成を更新してノードの健全性予測を有効にするには、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 時間以内に劣化する可能性があります。このドキュメントで説明するようにジョブ構成を構成した場合、Kueue はノードで新しいワークロードのスケジュール設定を行いません。

次のステップ