トレーニングと推論のワークロードを実行しているノードのホスト メンテナンスを行う

このドキュメントでは、Google Kubernetes Engine（GKE）クラスタ内のノードの基盤となる Compute Engine インスタンスのホスト メンテナンスを行う方法について説明します。このメンテナンスを積極的に管理する必要があるのは、GPU や TPU などのライブ マイグレーションを行わない特定のタイプの Compute Engine インスタンスのみです。このドキュメントで説明する戦略は、トレーニング ワークロードと推論ワークロードに適しています。個々のノードのホスト メンテナンスを手動で行う必要がある場合や、ワークロードが自動ホスト メンテナンスを許容できる場合は、GKE でホスト メンテナンスを行う方法をご覧ください。

これらの戦略では、ノードのグループに対してホスト メンテナンスを実行し、必要に応じて GKE クラスタのアップグレードを開始します。

トレーニング ワークロードのノードなど、1 回のダウンタイムで済むワークロードのノードには、並列戦略を使用します。推論ワークロードのノードなど、リソースの大部分の可用性を維持しながらダウンタイムをバッチ処理できるワークロードのノードには、ローリング戦略を使用します。

並列戦略を使用してトレーニング ワークロードのノードを更新する

この戦略では、アクセラレータを使用するノードのグループに対して同時に変更を行います。この戦略は、トレーニング ワークロードに使用できます。また、グループ内のすべてのノードと、それらのノードで実行されるワークロードに対して、完全なダウンタイムを 1 回だけ設けることが、変更を行う最も中断の少ない方法である他のタイプのワークロードにも使用できます。

この戦略は、次の手順で実行されます。

  1. ワークロードを停止する: ノードプールを選択し、そこで実行されているワークロードを停止するか、使用可能な他のノードにワークロードを移動します。
  2. ホスト メンテナンスをトリガーする: 選択したすべての ノードに同時にメンテナンス ラベルを適用し、すべてのノードでプロセスが完了するまで待ちます。
  3. GKE バージョンをアップグレードする: ノードの GKE バージョンを変更します。
  4. ワークロードを再起動する: すべてのホスト メンテナンスとアップグレードが完了したら、 ワークロードを再起動します。

提供されている手順では、単一のノードプールに対して変更を行います。ただし、この手順を調整して、複数のノードプールに対して同時に変更を行うこともできます。これらの手順を開始する前に、このワークロードをこれらのノードで実行する必要がない時間が数時間以上あることを確認してください。

基盤となる Compute Engine インスタンスと GKE ノードの両方で重要な変更を受け取る際の中断を最小限に抑えるには、このダウンタイムを利用してホスト メンテナンスと GKE バージョンのアップグレードの両方を行います。ただし、GKE ノードのバージョンをアップグレードしない場合は、ホスト メンテナンスのみを実行できます。

始める前の検討事項

始める前に、次の点を考慮してください。

  • ワークロードの再デプロイを避ける: PodDisruptionBudgetsによる不要な遅延を避けるため、 すべての手順が完了するまでワークロードを再デプロイしないでください。
  • 停止を計画する: ワークロードが一定期間 停止される可能性があることを確認します。これらの手順は、主にホスト メンテナンスに必要な時間のため、完了までに数時間かかります。

すべてのノードの更新を同時に行う

ホスト メンテナンスと、必要に応じて GKE バージョンのアップグレードを行うには、次の操作を行います。

  1. ワークロードを準備する: ワークロードを停止するか、最近のスナップショットまたはチェックポイントを 取得していることを確認します。

  2. ホスト メンテナンスを開始する: 選択したノードプールのすべてのノードにメンテナンス ラベルを適用します。

    kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwrite

    Compute Engine は、基盤となるインスタンスのドレインと更新を同時に開始します。このプロセスには数時間かかることがあります。詳細については、正常終了のプロセス をご覧ください。

  3. ホスト メンテナンスのステータスをモニタリングする: メンテナンスが完了すると、GKE は メンテナンス ラベルを削除します。メンテナンスが完了すると、Cloud Logging に次のメッセージを含むログが表示されます。

    Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

  4. 省略可: GKE ノードのバージョンをアップグレードする: 手順に沿って、ノードの GKE バージョンをアップグレードします。

ローリング戦略を使用して推論ワークロードのノードを更新する

この戦略では、推論ワークロードを実行する GKE ノードでメンテナンスを行う手動の方法について説明します。サービスの可用性を維持するために、ノードをバッチで更新します。この方法は、一定の割合のレプリカが一時的にオフラインになることを許容できるワークロードに最適です。

この戦略は、次の手順で実行されます。

  1. ノードを特定してバッチ処理する: 更新するノードプールを選択します。ワークロードの障害許容度に応じて、ノードをバッチにグループ化します。
  2. バッチを反復処理する: 各バッチにメンテナンス ラベルを適用し 、ラベルが削除されるまでノードのバッチをモニタリングします。
  3. GKE バージョンをアップグレードする: すべてのバッチでホスト メンテナンスが完了したら、GKE ノードのバージョンを変更します。

始める前の検討事項

始める前に、次の点を考慮してください。

  • デプロイを理解する: 成功するには、 ワークロードの分散、レプリカの配置、障害ドメインに関する詳細な知識が必要です。プロセス全体を通して十分なサービング容量を維持してください。
  • バッチサイズを計画する: ノードをバッチで更新します。各バッチのサイズは、ワークロードのフォールト トレランスによって決まります。考慮すべき要素は次のとおりです。
    • サービング モデルあたりのレプリカ数。
    • ノードと障害ドメイン間のレプリカの分散。
    • PodDisruptionBudgets を使用すると、同時にダウンする Pod の最大数を強制できます 。
    • 推奨事項: 管理を簡素化するには、 異なるレプリカセットに異なるノードプールを割り当てることを検討してください。これにより、 ノードプール レベルで障害ドメインを分離できます。
  • 時間制約を計算する: 次のタイミング要素を考慮してください。
    • 各バッチでホスト メンテナンスの手順を完了するまでに数時間かかることがあります。
    • 必要な期限内にすべてのメンテナンスが完了するように、最小バッチサイズを計算します。
      1. MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4)（ HOURS_TO_MAINTENANCE は使用可能な合計時間）。
      2. MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
    • 選択したバッチサイズは、MIN_PER_BATCH 以上である必要があります。
  • 特定のワークロード タイプを確認する: 構成タイプごとに次の点を考慮してください:
    • Mixture of Experts（MOE）: バッチ処理戦略 で、各モデルに必要な最小数のレプリカが維持されるようにします。
    • 分離されたサービング: バッチを計画する際に、分離された設定に関与するすべてのレプリカを追跡します。
    • マルチホスト ノードプール（TPU、MNNVL）: これらの構成では、通常、ノードプール全体を一度に停止します。複数のノードプールにまたがる障害ドメインを適切に計画します。

ローリング アップデートをバッチで実行する

ローリング アップデートを行うには、次の操作を行います。

  1. メンテナンス対象のノードを特定する: メンテナンスを 行うすべてのノードを特定し、このリストを保存します。ノードを特定するには、次のいずれかの方法を使用するか、手動で選択します。

    • アクセラレータ（TPU または GPU）を使用するクラスタ内のすべてのノードを取得します。

      kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'

    • 特定のノードプール内のすべてのノードを取得します。

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"

      NODE_POOL_NAME は、ノードプールの名前に置き換えます。

    • 特定のラベルが付いたすべてのノードを取得します。

      kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'

      LABEL は、ノードラベルに置き換えます。

  2. ノードをバッチに分割する: 特定したノードを均等な バッチに分割します。バッチサイズは、始める前の検討事項 セクションの 時間制約を計算する リスト項目で説明した式を使用して決定します。

  3. ホスト メンテナンスを行う: バッチごとに、次の操作を行います。

    1. ノードのバッチを選択し、メンテナンス ラベルを適用します。

      kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwrite

      LIST_OF_NODES_IN_BATCH は、バッチ内のノードのスペース区切りリストに置き換えます。例: node-1 node-2 node-3

    2. ホスト メンテナンスのステータスをモニタリングします。メンテナンスが完了すると、GKE はメンテナンス ラベルを削除します。メンテナンスが完了すると、Logging に次のメッセージを含むログが表示されます。

      Maintenance window has completed for this instance. All maintenance
notifications on the instance have been removed.

    3. すべてのバッチでホスト メンテナンスが完了するまで、残りのバッチごとに前の 2 つの手順を繰り返します。

  4. 省略可: GKE ノードのバージョンをアップグレードする: GKE ノードがまだメンテナンスが完了していないホストにデプロイされるシナリオを避けるため、 この手順はすべてのノードでホスト メンテナンスが完了した後にのみ実行してください。次のセクションの手順をご覧ください。

ノードの GKE バージョンをアップグレードする

同時にアップグレードするノードの数を検討してください。並列戦略では、ノードプール全体または複数のノードプールに対して同時にホスト メンテナンスを行いました。ローリング戦略では、ホスト メンテナンスをバッチで実行しました。ノードグループのサイズに基づいて、使用するアップグレード方法を決定します。

  • 並列戦略: ノードプールにゾーンあたり 20 個以下のノードがある場合は、サージ アップグレードを使用します。ノードプールにゾーンあたり 20 個を超えるノードがある場合は、ノードプールを削除して再作成します。
  • ローリング戦略: バッチにゾーンあたり、ノードあたり 20 個以下のノードがある場合は、サージ アップグレードを使用します。バッチにゾーンあたり、ノードプールあたり 20 個を超えるノードがある場合は、ノードを削除して再作成します。

サージ アップグレードを使用する

  1. サージ アップグレードを構成します。 maxUnavailable 設定を使用して、ノードプール内の ゾーンごとに同時に使用できなくなるノードの数を決定します。たとえば、ノードプールの 1 つのゾーンに 18 個のノードがある場合は、maxUnavailable フィールドの値を 18 に設定します。

    この設定は、余分な容量がない予約の容量を使用する場合に最適です。この 設定を使用する理由の詳細については、リソースが制限された 環境でのアップグレードをご覧ください。

  2. 次のコマンドを実行して、ノードプールをアップグレードします。複数のノードプールをアップグレードする場合は、ノードプールごとにこのコマンドを実行します。

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool NODE_POOL_NAME \
    --cluster-version VERSION \
    --location CONTROL_PLANE_LOCATION \
    --quiet

    次のように置き換えます。

ノードを削除して再作成する

ノードプールを削除し、新しいバージョンを使用して再作成します。

  1. ノードプールを削除します。

    gcloud container node-pools delete NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location CONTROL_PLANE_LOCATION

  2. --cluster-version フラグを使用して新しいバージョンを渡して、ノードプールを再作成します。ノードプールに推奨される自動アップグレード ターゲットを渡します。詳細については、 Standard クラスタのノード プールのアップグレード情報を取得するをご覧ください。 クラスタに推奨される自動アップグレード ターゲットがない場合は、 GKE リリースノートの 最新の バージョン アップデート エントリを確認してください。