GKE でのリソースの動的割り当てについて

動的リソース割り当て（DRA）を使用して、Google Kubernetes Engine（GKE）ワークロードに GPU を割り当てることができます。このドキュメントでは、DRA の基本、GKE での DRA の使用方法、DRA を使用するメリットについて説明します。

このドキュメントは、次のロールを対象としています。

次のことに精通している必要があります。

DRA の概要

DRA は Kubernetes の組み込み機能で、クラスタ内のハードウェアを Pod とコンテナ間で柔軟にリクエストして割り当て、共有できます。 DRA は、デバイス ベンダーとプラットフォーム管理者がリクエストと割り当てが可能なデバイスのクラスを宣言できるようにすることで、アクセラレータなどの接続されたハードウェアの割り当てのエクスペリエンスを改善します。アプリ オペレーターは、これらのクラス内で特定のデバイス構成をリクエストし、ワークロードでこれらの構成をリクエストできます。Kubernetes と GKE は、ワークロード リクエストに基づいて Pod のスケジューリング、ノードの割り当て、デバイスの割り当てを管理します。

たとえば、プラットフォーム管理者は NVIDIA A100 GPU のみを含むデバイスクラスを定義できます。アプリ オペレーターは、ワークロード要件に基づいて、そのデバイスクラスのデバイスをフィルタできます。たとえば、GPU メモリが 80 GB 以上のデバイスをフィルタできます。アプリ オペレーターがフィルタされた構成をリクエストするワークロードをデプロイすると、GKE は選択された条件を満たすノードに Pod を配置します。この例では、GKE は使用可能な A100（80 GB）GPU を持つノードを検索します。ワークロード マニフェストで特定のノードやデバイス構成を選択する必要はありません。

DRA のメリット

DRA がない場合、Kubernetes でのハードウェア デバイスの割り当てはデバイス プラグインに依存します。デバイス プラグインを使用してハードウェア リソースを Pod に接続するには、ノードラベルを使用して Pod を特定のノードに配置します。また、ノードのリソース全体を単一の Pod に割り当てるには、ノードに接続されているデバイスの正確な数をリクエストします。

DRA を使用すると、Pod へのデバイスの割り当ては、ストレージのボリュームの割り当てと同様になります。デバイスのクラスを定義し、そのクラス内のデバイスをリクエストして、リクエストされたデバイスをワークロードに割り当てます。DRA は、ワークロードとビジネスニーズに基づいてデバイスをフィルタするための、大幅に拡張可能なサーフェスを提供します。式とテンプレートを使用してハードウェアを要求し、Pod をスケジュールする DRA アプローチには、次のメリットがあります。

  • 宣言型デバイス割り当て: プラットフォーム管理者は、特定のタイプのワークロードまたはチームのデバイス構成を定義できます。
  • チーム間の複雑さの軽減: プラットフォーム管理者が特殊なハードウェア構成を持つノードをプロビジョニングする場合、アプリ オペレーターは特定の構成を持つノードを把握する必要がありません。プラットフォーム管理者は、ノードにラベルを付けたり、特定のノードとデバイスに関する情報をオペレーターに伝達したりする必要はありません。
  • デベロッパーの複雑さの軽減: Kubernetes は、参照するデバイス構成に基づいて Pod をスケジュールします。アプリ オペレーターは、ワークロードで特定のノードを選択する必要がなく、各 Pod がこれらのノードに接続されているデバイスの数を正確にリクエストする必要もありません。
  • 一元化されたインフラストラクチャ管理: プラットフォーム管理者は、特定のビジネス要件を満たすハードウェア構成を一元的に定義できます。たとえば、プラットフォーム管理者は、Tesla T4 GPU を搭載した小規模な推論構成と、H100 GPU を搭載した高性能構成を宣言できます。
  • 柔軟なハードウェア選択: CEL 式を使用して、特定の属性を持つデバイスをフィルタできます。式を使用すると、特定のワークロードに最適なデバイスを柔軟にフィルタできます。

DRA を使用する場面

GKE で DRA を使用する主な理由は、ワークロードのデバイスを柔軟にリクエストできる点です。一度マニフェストを作成すれば、マニフェストを変更することなく、異なるデバイスタイプの異なるクラスタにワークロードをデプロイできます。この柔軟性は、次のようなユースケースに最適です。

  • GPU の取得可能性を向上させる: GPU ハードウェアへのアクセスを必要とするワークロードの場合、GPU モデルを指定する代わりに、DRA を使用してクラスタ内の利用可能な任意の GPU をリクエストできます。これらのワークロードに特定の GPU メモリ（VRAM）要件がある場合は、最小メモリ量を備えたクラスタ内の任意の GPU をリクエストできます。このタイプの柔軟なリクエストにより、ワークロードが実行できる GPU ノードのセットが拡張され、リソースが使用できないためにワークロードがスケジュールされないリスクが軽減されます。

  • スケーリング中にノードの可用性を最適化する: ワークロードに必要なデバイスの数は、デバイスのタイプや機能などの要因によって異なる場合があります。GKE の ComputeClasses を使用すると、デバイスの可用性に基づいて、高速化された Pod を特定のノードプールに配置できます。次に、GKE が Pod を配置するノード内のデバイスを要求するように Pod を構成できます。

    ComputeClass で DRA を使用すると、スケジュールされていないワークロードのリスクを最小限に抑え、最適化されたハードウェアでワークロードを実行できます。

用語

オープンソースの Kubernetes と GKE などのマネージド Kubernetes プロバイダでは、次のコア DRA API 種類を使用します。

ResourceSlice
ResourceSlice は、ノードがアクセスできるクラスタ内の 1 つ以上のハードウェア デバイスの一覧を表示します。たとえば、単一の GPU にアクセスできるノードでは、ResourceSlice に GPU とノードの名前が一覧で表示されます。各ノードの DRA デバイス ドライバは、ResourceSlice を作成します。Kubernetes スケジューラは、ResourceSlice を使用して、ワークロード リクエストを満たすために割り当てるデバイスを決定します。
DeviceClass
DeviceClass は、ワークロードにリクエストできるデバイスのカテゴリ（GPU など）を定義します。一部のデバイス ドライバには、NVIDIA GPU の gpu.nvidia.com DeviceClass などの組み込み DeviceClass が用意されています。プラットフォーム管理者は、特定のデバイス構成を定義するカスタム DeviceClass を作成することもできます。
ResourceClaim

ResourceClaim を使用すると、Pod またはユーザーは DeviceClass 内の特定のパラメータをフィルタして、ハードウェア リソースをリクエストできます。ワークロードが ResourceClaim を参照すると、Kubernetes は指定されたパラメータに一致するデバイスをその ResourceClaim に割り当てます。

たとえば、1 つの A100（40 GB）GPU の ResourceClaim を作成し、その ResourceClaim を選択するワークロードをデプロイするシナリオを考えてみましょう。Kubernetes は、使用可能な A100（40 GB）GPU を ResourceClaim に割り当て、その GPU にアクセスできるノードに Pod をスケジュールします。

ResourceClaimTemplate

ResourceClaimTemplate は、Pod ごとの新しい ResourceClaim を自動的に作成するために Pod が使用できるテンプレートを定義します。ResourceClaimTemplate は、同様のデバイス構成にアクセスする必要がある複数のワークロードがある場合、特に、Deployment や StatefulSet などのワークロード コントローラを使用する場合に便利です。

アプリ オペレーターは ResourceClaimTemplates をデプロイし、ワークロードでテンプレートを参照します。Kubernetes は、指定されたテンプレートに基づいて各 Pod の ResourceClaim を作成し、デバイスを割り当てて Pod をスケジュールします。Pod が終了すると、Kubernetes は対応する ResourceClaim をクリーンアップします。

DRA API の種類の詳細については、DRA の用語をご覧ください。

DRA の仕組み

クラスタとワークロードで DRA を使用するプロセスは、StorageClass、PersistentVolumeClaim、PersistentVolume を使用して Pod のボリュームを動的にプロビジョニングするプロセスと似ています。

次の図は、クラスタ管理者とアプリ オペレーターが DRA を使用してデバイスを割り当てる手順を示しています。

この図では、クラスタ管理者とアプリ オペレーターは次の操作を行います。

  1. クラスタ管理者は、DRA をサポートするデバイス ドライバをノードにインストールします。
  2. クラスタ管理者は、40 GB を超えるメモリを搭載したすべての GPU など、特定の要件を満たすハードウェアをフィルタする DeviceClass を作成します。一部のデバイスには、組み込みの DeviceClass が含まれている場合があります。
  3. アプリケーション オペレーターは、デバイス構成をリクエストする ResourceClaimTemplates または ResourceClaims を作成します。各タイプのクレームの主なユースケースは次のとおりです。
    • ResourceClaim を使用すると、複数の Pod が同じデバイスへのアクセスを共有できます。
    • ResourceClaimTemplate を使用すると、Pod ごとの ResourceClaim を自動的に生成することで、複数の Pod が個別の類似デバイスにアクセスできます。
  4. アプリケーション オペレーターは、ResourceClaimTemplates または ResourceClaims をワークロード マニフェストに追加します。
  5. アプリケーション オペレーターは、ワークロードをデプロイします。

ResourceClaimTemplate または ResourceClaim を参照するワークロードをデプロイすると、Kubernetes は次のスケジューリング手順を実行します。

  1. ワークロードが ResourceClaimTemplate を参照している場合、Kubernetes はワークロードのインスタンス（Deployment の各レプリカなど）ごとに新しい ResourceClaim オブジェクトを作成します。
  2. Kubernetes スケジューラは、クラスタ内の ResourceSlice を使用して、使用可能な対象デバイスを各 Pod の ResourceClaim に割り当てます。
  3. スケジューラは、Pod の ResourceClaim に割り当てられたデバイスにアクセスできるノードに各 Pod を配置します。
  4. 宛先ノードの kubelet は、ノード上の DRA ドライバを呼び出して割り当てられたハードウェアをリソース リクエストに応じて Pod に接続します。

ResourceClaim と ResourceClaimTemplate を使用する場面

ResourceClaim または ResourceClaimTemplate を使用して、特定の要件を満たすデバイスが必要であることを Kubernetes に示すことができます。ResourceClaim が Pod で参照されると、Kubernetes は Kubernetes API サーバーの対応する ResourceClaim API リソースにデバイスを割り当てます。この割り当ては、ResourceClaim を作成したのがユーザーか、Kubernetes が ResourceClaimTemplate から ResourceClaim を作成したかに関係なく行われます。

ResourceClaim を作成して複数の Pod で参照すると、これらの Pod はすべて、Kubernetes が ResourceClaim に割り当てたデバイスにアクセスできます。たとえば、複数のレプリカを持つ Deployment マニフェストで特定の ResourceClaim を参照する場合、この共有アクセスが発生する可能性があります。しかし、割り当てられたデバイスが複数のプロセスで共有されるように構成されていない場合、Pod 間で共有デバイス アクセスにより意図しない動作が発生する可能性があります。

Pod に個別のデバイスを割り当てるには、ResourceClaimTemplate を使用します。これは、Kubernetes が個々の ResourceClaim を自動的に作成するために使用するテンプレートです。たとえば、複数のレプリカを持つ Deployment で ResourceClaimTemplate を参照すると、Kubernetes は複製された Pod ごとに個別の ResourceClaim を作成します。その結果、各 Pod はデバイスへのアクセスを他の Pod と共有せず、独自の割り当てデバイスを取得します。自動生成されたこれらの ResourceClaim は、対応する Pod のライフタイムにバインドされ、Pod が終了すると削除されます。同様のデバイス構成にアクセスする必要がある独立した Pod がある場合は、ResourceClaimTemplate を使用して、各 Pod にデバイスを個別に割り当てます。

次の表は、ResourceClaim を手動で作成する場合と、Kubernetes が ResourceClaimTemplate から ResourceClaim を作成する場合の違いを示しています。

表 1.ResourceClaim と ResourceClaimTemplate の比較
手動で作成した ResourceClaim 自動作成した ResourceClaim
自分で管理 Kubernetes が管理
複数の Pod から同じデバイスへのアクセスを提供 単一の Pod からデバイスへのアクセスを提供
Pod とは独立してクラスタ内に存在 対応する Pod のライフサイクルにバインド
特定のデバイスを共有する必要がある複数のワークロードに最適 独立したデバイス アクセスを必要とする複数のワークロードに最適

DRA と手動デバイス割り当ての比較

DRA を使用すると、接続されたデバイスの割り当てを、PersistentVolume の動的プロビジョニングと同様の方法で行えます。Kubernetes では、デバイス プラグインを使用してデバイスを割り当てることもできます。この方法では、次の手順で操作します。

  1. クラスタ管理者は、GPU などのデバイスが接続されたノードを作成します。
  2. クラスタ管理者は、特定のノードとその接続デバイスに関する情報をワークロード オペレーターに伝えます。
  3. ワークロード オペレーターは、ワークロード マニフェストで次のようにデバイスをリクエストします。
    • nodeSelector フィールドを使用して、GPU モデルなど、必要なデバイス構成を持つノードを選択します。
    • Pod 仕様の resources フィールドを使用して、コンテナが使用するデバイスの正確な数を指定します。

この手動割り当て方法では、アプリケーション オペレーターとクラスタ管理者が、特定のノードまたはノードプールに特定のデバイス構成があるかどうかについて連携する必要があります。ワークロード リクエストを調整してノード上のデバイスと一致させる必要があります。一致しない場合、デプロイは失敗します。これに対し、DRA では式を使用して属性に基づいてデバイスを柔軟にフィルタできます。また、ワークロード オペレーターがクラスタ内のノードの正確な構成を把握する必要もありません。

次の表は、DRA とデバイス プラグインを比較したものです。

表 2. DRA と手動デバイス割り当ての比較
DRA 手動割り当て
CEL 式を使用した柔軟なデバイス選択 セレクタとリソース リクエストを使用した特定のノードの選択
Kubernetes によるスケジューリングの決定 オペレーターがノードセレクタを使用して行うスケジューリングの決定
デバイスのフィルタリングはワークロードの作成とは別に行う デバイス フィルタリングはワークロード マニフェストで行う
プラットフォーム管理者が管理する、デバイスの集中型フィルタリングとニーズベースのクラス アプリケーション オペレーターによる分離されたデバイスのフィルタリング
アプリ オペレーターは、ノード容量、ノードラベル情報、各ノードに接続されているデバイスモデルを把握する必要はない アプリ オペレーターは、特定のモデルと特定のデバイスの数量が接続されているノードを把握する必要がある

DRA とインフラストラクチャの自動スケーリング

Standard モードのノードプール内のノード数を自動調整するには、クラスタ オートスケーラーを使用します。クラスタ オートスケーラーは、手動で作成されたノードプール（DRA ドライバを含むノードプールなど）で有効にできます。

DRA を使用するノードプールの場合、デバイス使用率は、クラスタ オートスケーラーがノードプール内のノードを追加および削除する方法に影響します。クラスタ オートスケーラーは、ノードプールのデバイス使用率を計算する際に、次の要素を考慮します。

  • リソースプール内のすべてのデバイスは、特定のノードに対してローカルである必要があります。ResourceSlice に複数のノードにアタッチされているデバイスのプールがある場合、クラスタ オートスケーラーはこれらのデバイスを無視します。
  • ノードプール内のすべてのデバイスは同じように重要で、同一です。
  • DRA デバイスは CPU やメモリよりも優先度が高くなります。DRA ノードプールでは、クラスタ オートスケーラーは CPU とメモリの使用率を無視します。

これらの要因により、DRA ノードプールと他のノードプールでスケールダウンの動作が異なることがあります。

DRA でサポートされている GKE デバイス

次の表に、GKE で DRA を使用してワークロードに割り当てることができるデバイスを示します。

表 3. GKE の DRA でサポートされているデバイス
DRA でサポートされているデバイス
GPU お使いのロケーションで利用可能な GPU タイプ。詳細については、GPU のロケーションをご覧ください。
ネットワーク インターフェース マネージド DRANET ドライバをインストールすることで、RDMA 対応インターフェースなどの複数のタイプのネットワーク インターフェース。詳細については、GKE マネージド DRANET を使用してネットワーク リソースを割り当てるをご覧ください。

制限事項

DRA を使用する場合は、次の制限事項が適用されます。

  • 動作モード: DRA は標準モードのクラスタでのみ使用できます。

  • アクセラレータ タイプ: プレビュー期間中、GKE の DRA は GPU のみをサポートします。

  • GPU:

  • ネットワーク インターフェース（プレビュー）: 「GKE マネージド DRANET を使用してネットワーク リソースを割り当てる」の制限事項をご覧ください。

  • 自動スケーリング:

    • インストールするサードパーティの DRA ドライバの場合、クラスタ オートスケーラーでは、ノードプールに少なくとも 1 つのノードが必要です。サードパーティ ドライバを使用するノードプールがゼロノードにスケーリングされないようにするには、ノードの最小数を 1 以上に設定します。
    • クラスタ オートスケーラーは、サードパーティの DRA ドライバでは正しく動作しない可能性があります。サードパーティ ドライバを使用する場合は、ドライバが特定のノードのローカル デバイスの情報のみを公開していることを確認します。
    • 静的 ResourceClaim を使用して Pod 間でデバイス アクセスを共有する自動スケーリング ノードプール内の DaemonSet の場合、自動スケーリングは最大 128 個の DaemonSet Pod をサポートします。この制限を回避するには、次のいずれかを行います。
    • Pod が ResourceClaim を参照し、プリエンプション ポリシーを PreemptLowerPriority に設定する PriorityClass を持つ場合、自動スケーリングのレイテンシが増加する可能性があります。PreemptLowerPriority は PriorityClass のデフォルトのプリエンプション ポリシーであるため、PriorityClass で preemptionPolicy フィールドが Never に明示的に設定されていることを確認してください。詳細については、非プリエンプト PriorityClass をご覧ください。

このセクションでは、DRA を使用してデバイスをワークロードに割り当てるプラットフォーム管理者またはアプリ オペレーター向けの推奨事項について説明します。DRA は、GKE と Kubernetes の両方で、接続されたデバイスをリクエストする方法を大きく変更します。クロスデバイス フォールバックやデバイスのきめ細かいフィルタリングと選択など、より高度なユースケースを活用するには、次のガイダンスを検討してください。

次のステップ