Container Compute Service:GPU-HPN ノードでの GPU 共有の使用

リソース設定と QoS

共有 GPU リソースは、Kubernetes の requests/limits 制約を使用して記述されます。計算能力と GPU メモリをパーセンテージで設定できます。この機能は、limits が requests よりも大きいリソース記述もサポートしています。これにより、複数の Pod が同時に GPU リソースを競合する可能性があります。ACK は、共有 GPU リソースに対してサービス品質 (QoS) を定義しています。ノード上の複数の Pod が同時に GPU リソースを使用する場合、Pod はキューに入れられ、プリエンプションがトリガーされることがあります。以下に例を示します：

...
resources:
  requests:  # ノードにスケジュールできる Pod の数を制御します。
    alibabacloud.com/gpu-core.percentage: 10         # Pod が必要とする計算能力のパーセンテージ。
    alibabacloud.com/gpu-memory.percentage: 10       # Pod が必要とする GPU メモリのパーセンテージ。
  limits:    # 実行時に使用できるリソースの上限を制御します。影響の詳細については、設定手順をご参照ください。
    alibabacloud.com/gpu-core.percentage: 100        # 計算能力使用量の上限。
    alibabacloud.com/gpu-memory.percentage: 100      # GPU メモリ使用量の上限。この上限を超えると、CUDA OOM エラーが発生します。
...

オペレーティングシステムのプロセス管理メカニズムと同様に、GPU 共有モジュールは Pod を休止状態、準備完了状態、実行中状態の 3 つの状態に分類します。状態遷移のプロセスを次の図に示します。

• Pod が開始されると、休止状態になります。

• Pod が GPU リソースを使用しようとすると、準備完了状態になります。その後、GPU 共有モジュールは優先度ポリシーに基づいて Pod に GPU リソースを割り当てます。

• Pod に GPU リソースが割り当てられると、実行中状態になります。

• すべてのリソースが割り当てられた後も準備完了状態の Pod が存在する場合、Pod 間のリソースの公平性を確保するためにプリエンプションメカニズムがトリガーされます。

• Pod がプリエンプションされると、GPU リソースを占有しているプロセスが強制終了され、Pod は休止状態に戻ります。

リソース共有モデル

GPU 共有は共有モデルに基づいており、複数の Pod が単一の GPU カード上で同時に実行できます。ACK は現在、次の共有モデルをサポートしています：

例：Notebook シナリオで share-pool モデルを使用してオフピーク時のリソース使用を行う

Notebook 開発では、アプリケーションは通常、リソースを長時間占有しません。share-pool モデルを使用すると、Pod はオフピーク時に異なる GPU カード上で実行できます。Pod はリソースを必要とするときにのみ、準備完了キューに入ってリソースを待ちます。

以下は、Notebook シナリオのユースケースです：

Pod A と Pod B は `requests=0.5` および `limits=0.5` で設定されています。Pod C と Pod D は `requests=0.5` および `limits=1` で設定されています。`requests` の値に基づき、これらの Pod は 2 つの GPU を持つ単一の GPU-HPN ノードにスケジュールできます。

時間 T1：

1. Pod A と Pod C がリソースを占有しています。Pod B と Pod D は準備完了キューにあり、スケジューリングを待っています。

2. GPU 共有モジュールは、キューの先頭にある Pod D にリソースを割り当てようとします。しかし、GPU 0 には 0.5 GPU のアイドルリソースしかありません。Pod D の `request` は 0.5 であり、利用可能な容量で満たすことができますが、その `limit` は 1 です。同じ GPU 上で Pod A と Pod D を実行するとリソースの競合が発生するため、GPU 共有モジュールは Pod D をキューに保持します。

時間 T2 - フェーズ 1：

1. Pod C のタスクが完了し、休止キューに入ります。

2. GPU 1 がアイドル状態になると、そのリソースが Pod D に割り当てられます。

時間 T2 - フェーズ 2：

Pod B にリソースが割り当てられます。Pod B の `limit` は 0.5 であるため、リソースの競合なしに GPU 0 上で Pod A と同時に実行できます。

手順 1：GPU-HPN ノードへのラベルの追加

1. GPU-HPN ノードを表示します。

   重要

   この機能を有効にする前に、ノード上で排他的な GPU リソースをリクエストする Pod を削除する必要があります。CPU とメモリリソースのみをリクエストする Pod を削除する必要はありません。

   kubectl get node -l alibabacloud.com/node-type=reserved

   期待される出力：

   NAME                     STATUS   ROLES   AGE   VERSION
   cn-wulanchabu-c.cr-xxx   Ready    agent   59d   v1.28.3-aliyun

2. GPU 共有機能を有効にするには、ノード cn-wulanchabu-c.cr-xxx にラベル alibabacloud.com/gpu-share-policy=share-pool を追加します。

   $ kubectl label node cn-wulanchabu-c.cr-xxx alibabacloud.com/gpu-share-policy=share-pool

手順 2：ノードの有効化ステータスの確認

ノードで機能が有効になるのを待ってから、有効化ステータスを確認します。capacity フィールドに GPU 共有リソースが表示されます。conditions フィールドでは、GPUSharePolicyValid が True になっています。これは、機能が有効になっていることを示します。

$ kubectl get node cn-wulanchabu-c.cr-xxx -o yaml

GPU 共有ポリシーが有効になると、ノードのステータスが更新されます。期待される出力：

# 実際の出力は異なる場合があります。
apiVersion: v1
kind: Node
spec: 
  # ...
status:
  allocatable:
    # GPU 共有リソースの説明
    alibabacloud.com/gpu-core.percentage: "1600"
    alibabacloud.com/gpu-memory.percentage: "1600"
    # 機能が有効になると、CPU、メモリ、ストレージリソースが GPU 共有モジュール用に予約されます。
    cpu: "144"
    memory: 1640Gi
    nvidia.com/gpu: "16"
    ephemeral-storage: 4608Gi
  capacity:
    # GPU 共有リソースの説明
    alibabacloud.com/gpu-core.percentage: "1600"
    alibabacloud.com/gpu-memory.percentage: "1600"
    cpu: "176"
    memory: 1800Gi
    nvidia.com/gpu: "16"
    ephemeral-storage: 6Ti
  conditions:
  # GPU 共有ポリシー設定が有効かどうかを示します。
  - lastHeartbeatTime: "2025-01-07T04:13:04Z"
    lastTransitionTime: "2025-01-07T04:13:04Z"
    message: gpu share policy is valid.
    reason: Valied
    status: "True"
    type: GPUSharePolicyValid
  # 現在のノードで有効な GPU 共有ポリシーを示します。
  - lastHeartbeatTime: "2025-01-07T04:13:04Z"
    lastTransitionTime: "2025-01-07T04:13:04Z"
    message: gpu share policy is share-pool.
    reason: share-pool
    status: "True"
    type: GPUSharePolicy

GPU 共有リソースの設定項目に関する詳細については、「ノード設定」をご参照ください。

手順 3：GPU 共有リソース仕様を持つ Pod のデプロイ

1. gpu-share-demo.yaml という名前のファイルを作成します。ノードと同じ share-pool モデルを使用するように設定します。

   apiVersion: v1
   kind: Pod
   metadata:
     labels:
       alibabacloud.com/compute-class: "gpu-hpn"
       # Pod の GPU 共有モデルを、ノード設定と同じ share-pool に設定します。
       alibabacloud.com/gpu-share-policy: "share-pool" # static
     name: gpu-share-demo
     namespace: default
   spec:
     containers:
     - name: demo
       image: registry-cn-wulanchabu-vpc.ack.aliyuncs.com/acs/stress:v1.0.4
       args:
         - '1000h'
       command:
         - sleep
       # リソース記述で GPU 共有リソース gpu-core.percentage と gpu-memory.percentage を指定します。
       # request と limit の影響に関する詳細については、設定手順をご参照ください。
       resources:
         limits:
           cpu: '5'
           memory: 50Gi
           alibabacloud.com/gpu-core.percentage: 100
           alibabacloud.com/gpu-memory.percentage: 100
         requests:
           cpu: '5'
           memory: 50Gi
           alibabacloud.com/gpu-core.percentage: 10
           alibabacloud.com/gpu-memory.percentage: 10

2. サンプル Pod をデプロイします。

   kubectl apply -f gpu-share-demo.yaml

手順 4：Pod の GPU 共有リソース使用量の確認

コンテナーにログインして、Pod の GPU 共有リソース使用量を確認します。

kubectl exec -it pod gpu-share-demo -- /bin/bash

`nvidia-smi` などのコマンドを使用して、コンテナーの GPU リソース割り当てと使用状況を表示します。実際の出力は異なる場合があります。

(オプション) 手順 5：ノードでの GPU 共有ポリシーの無効化

1. GPU 共有機能を使用する Pod を削除します。

   $ kubectl delete pod gpu-share-demo

2. ノードで GPU 共有機能を無効にします。

   $ kubectl label node cn-wulanchabu-c.cr-xxx alibabacloud.com/gpu-share-policy=none

3. ノードのポリシー設定ステータスを再度確認します。

   $ kubectl get node cn-wulanchabu-c.cr-xxx -o yaml

   期待される出力：

   apiVersion: v1
   kind: Node
   spec: 
     # ...
   status:
     allocatable:
       # 機能が無効になると、予約されていた CPU とメモリリソースは初期値に戻ります。
       cpu: "176"
       memory: 1800Gi
       nvidia.com/gpu: "16"
       ephemeral-storage: 4608Gi
     capacity:
       cpu: "176"
       memory: 1800Gi
       nvidia.com/gpu: "16"
       ephemeral-storage: 6Ti
     conditions:
     # GPU 共有ポリシー設定が有効かどうかを示します。
     - lastHeartbeatTime: "2025-01-07T04:13:04Z"
       lastTransitionTime: "2025-01-07T04:13:04Z"
       message: gpu share policy config is valid.
       reason: Valid
       status: "True"
       type: GPUSharePolicyValid
     # 現在のノードで有効な GPU 共有ポリシーを示します。
     - lastHeartbeatTime: "2025-01-07T04:13:04Z"
       lastTransitionTime: "2025-01-07T04:13:04Z"
       message: gpu share policy is none.
       reason: none
       status: "False"
       type: GPUSharePolicy

ノード設定

apiVersion: v1
kind: Node
metadata:
  labels:
    # 機能を有効にし、share-pool ポリシーを使用します。値には他のポリシーを指定できます。
    alibabacloud.com/gpu-share-policy: share-pool

apiVersion: v1
kind: Node
...
metadata:
  annotations:
    alibabacloud.com/gpu-share-qos-config: '{"preemptEnabled": true, "podMaxDurationMinutes": 120, "reservedEphemeralStorage": "1.5Ti"}'
...

Pod 設定

機能が有効になった後、Pod の GPU 共有リソースラベルを設定することで使用できます。

apiVersion: v1
kind: Pod
metadata:
  labels:
    # gpu-hpn コンピュートクラスのみがサポートされています。
    alibabacloud.com/compute-class: "gpu-hpn"
    # Pod の GPU 共有モデルを、ノード設定と同じ share-pool に設定します。
    alibabacloud.com/gpu-share-policy: "share-pool"
  name: gpu-share-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: registry-cn-wulanchabu-vpc.ack.aliyuncs.com/acs/stress:v1.0.4
    args:
      - '1000h'
    command:
      - sleep
    resources:
      limits:
        cpu: '5'
        memory: 50Gi
        alibabacloud.com/gpu-core.percentage: 100
        alibabacloud.com/gpu-memory.percentage: 100
      requests:
        cpu: '5'
        memory: 50Gi
        alibabacloud.com/gpu-core.percentage: 10
        alibabacloud.com/gpu-memory.percentage: 10

設定項目は次のように記述されます：

GPU リソースが利用できない場合、準備完了キューの Pod はどうなりますか？

GPU 共有 Pod がリソースを待っている間、定期的にメッセージを出力します。以下はサンプルメッセージです。

You have been waiting for ${1} seconds. Approximate position: ${2}

${1} パラメーターは待機時間を示し、${2} パラメーターは準備完了キューでの現在の位置を示します。

GPU 共有モードに固有の Pod モニタリングメトリックは何ですか？

GPU 共有リソースを使用する Pod については、次のメトリックを使用してリソース使用量を確認できます。

DCGM_FI_POOLING_STATUS{NodeName="cn-wulanchabu-c.cr-xxx",pod="gpu-share-demo",namespace="default"} 1

DCGM_FI_POOLING_POSITION{NodeName="cn-wulanchabu-c.cr-xxx",pod="gpu-share-demo",namespace="default"} 1

Pod が GPU 共有を使用する場合、GPU 使用率メトリックはどのように異なりますか？

Pod の GPU 使用率メトリックは以前と同じです。ただし、GPU 共有を使用する Pod の場合、メトリックのラベルと意味が異なります。

• ACK が提供する Pod モニタリングデータでは、GPU 計算能力使用率や GPU メモリ使用量などのメトリックは、排他的な GPU シナリオと同様に、GPU カード全体に基づいた絶対値です。

• `nvidia-smi` などのコマンドを使用して Pod 内で確認できる GPU メモリ使用量は、排他的な GPU シナリオと同様に絶対値です。ただし、計算能力使用率は相対値であり、分母は Pod の limit です。

• Pod の GPU 使用率メトリックの ID 番号などのデバイス情報は、ノード上の実際の ID に対応します。番号付けは必ずしも 0 から始まるとは限りません。

• share-pool 共有モデルの場合、Pod がプールから異なる GPU デバイスを弾力的に使用するため、メトリックのデバイス番号が変更されることがあります。

クラスター内の一部のノードでのみ GPU 共有が有効になっている場合、排他的な GPU Pod とのスケジューリング競合を回避するにはどうすればよいですか？

ACK クラスターのデフォルトスケジューラは、Pod とノードのタイプを自動的に照合して、スケジューリングの競合を回避します。

カスタムスケジューラを使用する場合、ノードの容量に GPU デバイスリソースと GPU 共有リソースの両方が含まれるため、排他的な GPU Pod が GPU 共有ノードにスケジュールされる可能性があります。次のいずれかのソリューションを選択できます：

• ソリューション 1：ACK ノードの設定ラベルと condition プロトコルを自動的に検出し、不一致のタイプのノードを除外するスケジューラプラグインを作成します。詳細については、「Scheduling Framework」をご参照ください。

• ソリューション 2：Kubernetes のラベルまたは Taint を使用します。GPU 共有が有効になっているノードにラベルまたは Taint を追加します。次に、排他的な GPU Pod と共有 GPU Pod に異なるアフィニティポリシーを設定します。

GPU 共有 Pod がプリエンプションされた場合、どのような情報が得られますか？

share-pool 共有モデルの場合、プリエンプションがトリガーされると、Pod には Event と Condition があります。Event は非構造化データ形式です。構造化データを読み取るには、対応する Condition の `reason` および `status` フィールドから取得できます。詳細は次のとおりです。

# 現在の Pod の GPU リソースがプリエンプションされたことを示します。プリエンプションした Pod の名前は <new-pod-name> です。
Warning  GPUSharePreempted  5m15s  gpushare   GPU is preempted by <new-pod-name>.
# 現在の Pod が別の Pod の GPU リソースをプリエンプションしたことを示します。プリエンプションされた Pod の名前は <old-pod-name> です。
Warning  GPUSharePreempt    3m47s  gpushare   GPU is preempted from <old-pod-name>.

- type: Interruption.GPUShareReclaim # GPU 共有 Pod プリエンプションのイベントタイプ。
  status: "True" # True は、プリエンプションまたはプリエンプションされたアクションが発生したことを示します。
  reason: GPUSharePreempt # GPUSharePreempt は、この Pod が別の Pod をプリエンプションしたことを示します。GPUSharePreempted は、この Pod が別の Pod によってプリエンプションされたことを示します。
  message: GPU is preempted from <old-pod-name>. # イベントと同様のユーザーフレンドリーなメッセージ。
  lastTransitionTime: "2025-04-22T08:12:09Z" # プリエンプションが発生した時刻。
  lastProbeTime: "2025-04-22T08:12:09Z"

Notebook シナリオでノード上により多くの Pod を実行するにはどうすればよいですか？

GPU 共有が有効になっている Pod について、ACK では `request` が `limit` より小さい CPU およびメモリ仕様を設定することもできます。これにより、ノードリソースを最大限に活用できます。ノードに送信された Pod のリソースの `limit` の合計がノードの割り当て可能なリソースを超えると、Pod は CPU およびメモリリソースを競合することに注意してください。ノードのリソース使用率データを確認することで、CPU とメモリのリソース競合を分析できます。詳細については、「ACK GPU-HPN ノードレベルのモニタリングメトリック」をご参照ください。Pod の場合、CPU リソースの競合は Pod の CPU Steal Time に反映されます。メモリリソースの競合は、マシン全体のアウトオブメモリ (OOM) エラーをトリガーし、一部の Pod が強制終了される原因となります。リソース競合による Pod のサービス品質への影響を避けるために、アプリケーションの特性に基づいて Pod の優先順位とリソース仕様を計画してください。