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 を使用するときにノードの健全性予測を有効にするには、ワークロードを開始する前に、健全性予測の値と、サポートされている場合はトポロジ要件を確認するように 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 はノードで新しいワークロードのスケジューリングを回避します。

次のステップ