このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Amazon EKS でハードウェアデバイスを管理する
Amazon EKS は、EKS クラスターで特殊なハードウェアデバイスを管理できるように、動的リソース割り当て (DRA) とデバイスプラグインという 2 つの Kubernetes メカニズムをサポートしています。どちらも、ワークロードが NVIDIA GPU や AWS Trainium チップなどのハードウェアアクセラレーターや、Elastic Fabric Adapter (EFA) などのハイパフォーマンスネットワークデバイスにアクセスできるようにするメカニズムです。
Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードで [静的キャパシティのプロビジョニング]
この 2 つの Kubernetes 機能に関する全般的な情報については、動的リソース割り当て
動的リソース割り当てとデバイスプラグインの比較
Kubernetes デバイスプラグインは、これまで特殊なハードウェアを Kubernetes ワークロードに公開する際に第一に使用されてきたメカニズムです。ユーザーからのコンテナリソースのリクエストや制限を受けて、デバイスを拡張リソース (nvidia.com/gpu や aws.amazon.com/neuroncore など) としてアドバタイズします。広くサポートされ、使用されていますが、次のような制限があります。
-
デバイスは、属性ベースのフィルタリングがない不透明な整数カウントとしてリクエストされます。
-
コンテナまたはポッド間でデバイスを共有する機能はサポートされていません。
-
トポロジー認識割り当てをデバイスタイプ全体で表現力豊かに行う機能はありません。
-
インテリジェントに配置するには、多くの場合、カスタムスケジューラ拡張機能が必要です。
動的リソース割り当て (DRA) は、これらの制限に対処するために Kubernetes バージョン 1.34 で一般公開された Kubernetes 機能です。DRA により、デバイスドライバーは ResourceSlice オブジェクトを介して豊富なデバイス属性を Kubernetes スケジューラに発行します。デバイスをリクエストするには、DeviceClass カテゴリを参照する ResourceClaim オブジェクトおよび ResourceClaimTemplate オブジェクトを使用します。
DRA では次のことが可能になります。
-
Common Expression Language (CEL)
式を使用して属性ベースでデバイスを選択する。 -
トポロジ認識割り当てにより、複数のデバイスが同じ PCIe スイッチまたは NUMA ドメインに共存できるようになる。
-
ResourceClaimリファレンスを共有することで、複数のコンテナやポッド間でデバイスを共有する。 -
MIG またはタイムスライシングを使用する場合の NVIDIA GPU の動的パーティショニングと共有
Amazon EKS 向け DRA ドライバー
次の DRA ドライバーは、Amazon EKS クラスターで特殊なハードウェアデバイスを管理する場合によく使用されます。
- NVIDIA DRA ドライバー
-
GitHub の GPU 用 NVIDIA DRA ドライバー
は、NVIDIA GPU の柔軟な割り当てと動的な設定を可能にします。NVIDIA DRA ドライバーを使用した GPU の管理の詳細については Amazon EKS で NVIDIA DRA ドライバーまたはデバイスプラグインを使用する を、EC2 Grace-Blackwell インスタンスを使用したマルチノード NVLink (MNNVL) ワークロードでの ComputeDomainsの使用の詳細については Amazon EKS で P6e-GB200 UltraServer を使用する を参照してください。 - EFA DRA ドライバー
-
EFA DRA ドライバー (GitHub の DRANET
) は、EFA インターフェイスをトポロジー的にローカルな GPU または Neuron デバイスとペアリングするトポロジー認識スケジューリングを使用して Elastic Fabric Adapter (EFA) デバイスの割り当てを管理し、ポッド間でのデバイス共有をサポートします。詳細については、「Amazon EKS で EFA デバイスを管理する」を参照してください。 - Neuron DRA ドライバー
-
Neuron DRA ドライバーは、トポロジー認識スケジューリング、コネクテッドデバイスサブセット割り当て、Logical NeuronCore (LNC) 設定により、AWS Trainium と AWS Inferentia2 のデバイス割り当てを管理します。カスタムスケジューラ拡張機能は必要ありません。詳細については、「Amazon EKS で Neuron デバイスを管理する」を参照してください。
Amazon EKS 用のデバイスプラグイン
次のデバイスプラグインは、Amazon EKS クラスターで特殊なハードウェアデバイスを管理する場合によく使用されます。
- NVIDIA デバイスプラグイン
-
GitHub の NVIDIA デバイスプラグイン
は、NVIDIA GPU を nvidia.com/gpu拡張リソースとしてアドバタイズし、GPU の正常性を追跡します。 - EFA デバイスプラグイン
-
EFA デバイスプラグインは、各ノードで使用可能な EFA デバイスをすべて検出して、
vpc.amazonaws.com/efa拡張リソースとしてアドバタイズします。 - Neuron デバイスプラグイン
-
Neuron デバイスプラグイン
は、Neuron ハードウェアを aws.amazon.com/neuroncoreおよびaws.amazon.com/neuron拡張リソースとして公開します。各ノードで使用可能な Neuron デバイスを検出して、割り当て可能なリソースとしてアドバタイズし、そのライフサイクルを管理します。
考慮事項
Amazon EKS で DRA ドライバーを使用する前に、以下の考慮事項を検討してください。
-
DRA は Kubernetes バージョン 1.33 以降の Amazon EKS で使用できますが、GitHub のアップストリーム Kubernetes の問題
があるため、Kubernetes バージョン 1.34 以降をお勧めします。クラスターコントロールプレーンとノードが、DRA をサポートする Kubernetes バージョンを実行している必要があります。 -
DRA は、現在 EKS Auto Mode と互換性がありません。
-
動的にプロビジョニングされたキャパシティを使用する場合、DRA は現在 Karpenter と互換性がありません。DRA ドライバーでは、Karpenter の静的キャパシティプロビジョニング、EKS マネージドノードグループ、またはセルフマネージドノードを使用する必要があります。
-
同じノードで同じデバイスタイプの DRA ドライバーとデバイスプラグインを同時に実行することはできません。対応する DRA ドライバーをインストールする前に、デバイスプラグインをアンインストールするか、別のノードにデプロイします。同じノード上の同じデバイスに対して DRA ドライバーとデバイスプラグインの両方を実行すると、基盤となるハードウェアデバイスがサイレントオーバーサブスクリプションになる可能性があります。
-
DRA で使用される Kubernetes API リソース (
ResourceClaim、ResourceClaimTemplate、DeviceClass) は、デバイスプラグインのもの (resource.limits、resource.requests) とは異なります。DRA を使用すると、ワークロードの仕様を変更することなく、デバイスプラグインの拡張リソースを管理できます。DRA の Kubernetes リソースの詳細については、Kubernetes ウェブサイトの「Kubernetes ドキュメント」を参照してください。 -
NVIDIA、EFA、および Neuron 用の DRA ドライバーは、EKS 最適化 AL2023 AMI と Bottlerocket AMI の両方と互換性があります。Bottlerocket で NVIDIA DRA ドライバーを使用している場合は、Bottlerocket NVIDIA バリアントに含まれている NVIDIA デバイスプラグインを無効にします。
-
デバイスプラグインは、すべての Kubernetes バージョンで引き続き完全にサポートされます。
DRA の ResourceClaim と ResourceClaimTemplate
DRA を使用する場合は、ResourceClaim オブジェクトまたは ResourceClaimTemplate オブジェクトを使用してデバイスをリクエストします。これらの 2 つのリソースタイプは、目的も異なれば、ライフサイクルの動作も異なります。
- ResourceClaim
-
ResourceClaimは、いずれのポッドからも独立して作成する名前付き Kubernetes オブジェクトです。resourceClaimNameフィールドを使用してポッド仕様で名前で参照します。ResourceClaimには以下の特徴があります。-
ポッドで参照するには、ポッドの作成前にクラスターに存在している必要があります。クレームが存在しない場合、ポッドは保留状態のままになります。
-
ポッドで参照しているかどうかに関係なく、明示的に削除するまで保持されます。
-
複数のポッドで同じ
ResourceClaimを参照できるため、デバイス共有が可能です。同じクレームを参照するすべてのポッドで、割り当てられた同じデバイスへのアクセスを共有し、同じノードにスケジュールされます。ResourceClaimは、複数のポッドで同じデバイスへのアクセスを共有する必要がある場合や、単一のポッドのライフタイムを超えてクレームを保持する必要がある場合に使用します。
-
- ResourceClaimTemplate
-
ResourceClaimTemplateは、各ポッドの固有のResourceClaimを Kubernetes で自動的に生成するために使用するテンプレートを定義します。resourceClaimTemplateNameフィールドを使用してポッド仕様で参照します。ResourceClaimTemplate自体はいずれのポッドにもバインドされません。個別に保持される再利用可能なテンプレートです。ResourceClaimTemplateには以下の特徴があります。-
テンプレートを参照するポッドごとに、新しい
ResourceClaimが Kubernetes で作成されます。各ポッドに独自のデバイスのセットが割り当てられます。 -
生成された
ResourceClaimは、作成をトリガーしたポッドのライフサイクルにそれぞれバインドされます。ポッドが削除されると、それに関連する生成されたResourceClaimも削除されます。ResourceClaimTemplate自体に影響はなく、以降のポッドに対する新しいクレームの生成に引き続き使用されます。ResourceClaimTemplateは、ワークロードの各ポッドに同様の設定を持つ独自の専用デバイスが必要な場合に使用します。例えば、各ポッドに独自の GPU デバイスまたは EFA デバイスが必要な並列実行を使用するジョブでは、ポッドにResourceClaimTemplateを使用します。
-
次の表は、ResourceClaim と ResourceClaimTemplate の違いをまとめたものです。
| 動作 | ResourceClaim | ResourceClaimTemplate |
|---|---|---|
|
作成 |
ポッドで参照する前に手動で作成します。 |
ポッドごとに Kubernetes で自動的にクレームが生成されます。 |
|
ライフサイクル |
削除するまで保持されます。 |
テンプレートは削除するまで保持されます。生成された |
|
ポッド間でのデバイス共有 |
サポート対象。複数のポッドで同じクレームを参照できます。 |
サポート外。各ポッドに個別のクレームが割り当てられます。 |
|
ポッド仕様のフィールド |
|
|
ResourceClaim オブジェクトを使用してポッド間で EFA デバイスを共有する例については、「複数のポッド間で EFA デバイスを共有する」を参照してください。ResourceClaimTemplate オブジェクトでトポロジー認識割り当てを使用する例については、「EFA と GPU/Neuron デバイスのトポロジー認識割り当て」を参照してください。
トピック
