**このページの改善にご協力ください** このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。 # Amazon EKS で EFA デバイスを管理する [Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html) (EFA) は Amazon EC2 インスタンス用のネットワークデバイスであり、人工知能、機械学習、およびハイパフォーマンスコンピューティング (HPC) のワークロード用にハイパフォーマンスのノード間通信と RDMA (リモートダイレクトメモリアクセス) を実現します。Amazon EKS は、EKS クラスターで EFA デバイスを管理できるように、*EFA 動的リソース割り当て (DRA) ドライバー (DRANET)* と *EFA デバイスプラグイン*という 2 つのメカニズムをサポートしています。 Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードで [[静的キャパシティのプロビジョニング]](https://karpenter.sh/docs/concepts/nodepools/#static-nodepool) を使用する場合は、Kubernetes バージョン 1.34 以降の新しいデプロイに DRA ドライバーを使用することをお勧めします。DRA は、現在 EKS Auto Mode ではサポートされていません。EFA DRA ドライバーを使用すると、EFA インターフェイスをトポロジー的にローカルな GPU または Neuron デバイスとペアリングするトポロジー認識割り当てを設定し、ポッド間でデバイスを共有できます。 ## EFA DRA ドライバーと EFA デバイスプラグイン | 機能 | EFA DRA ドライバー | EFA デバイスプラグイン | | --- | --- | --- | | 最小限必要な Kubernetes バージョン | 1.34 | EKS でサポートされているすべての Kubernetes バージョン | | EKS コンピューティング | Karpenter (静的キャパシティのみ)、マネージドノードグループ、セルフマネージドノード | EKS オートモード、Karpenter、マネージドノードグループ、セルフマネージドノード | | EKS 最適化 AMI | AL2023、Bottlerocket | AL2023、Bottlerocket | | デバイスアドバタイズ | デバイスタイプ、トポロジー、PCIe ローカリティなど、`ResourceSlice` オブジェクトによる豊富な属性 | `vpc.amazonaws.com/efa` 拡張リソースの整数カウント | | GPU-EFA アフィニティ | DRA ネイティブトポロジー認識 | 自動トポロジー認識 (EKS 最適化 AL2023 AMI のみ) | | Neuron-EFA アフィニティ | DRA ネイティブトポロジー認識 | 自動トポロジー認識 (EKS 最適化 AL2023 AMI のみ) | | デバイス共有 | 共有の `ResourceClaim` を参照することにより複数のポッドで同じ EFA デバイスを共有できる | サポート外。各 EFA デバイスは 1 つのポッドにのみ割り当てられる。 | ## EFA インターフェイスを備えた EKS ノードを作成する EFA インターフェイスを備えた EKS ノードを作成すると、インスタンスのプロビジョニング中に EFA インターフェイスがインスタンスにアタッチされます。デバイスごとの EFA 設定をカスタマイズし、EKS Auto Mode、Karpenter、EKS マネージドノードグループ、または EKS セルフマネージドノードグループで[プレイスメントグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)を使用できます。EKS Auto Mode では、各ネットワークインターフェイスの設定を `advancedNetworking.networkInterfaces` の `NodeClass` 経由で渡します。Karpenter では、`EC2NodeClass` を介して各ネットワークインターフェイスの設定を渡します。EKS マネージドノードグループまたはセルフマネージドノードでは、[起動テンプレート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)を使用して各ネットワークインターフェイスの設定を渡します。 [`eksctl`](install-kubectl.md#eksctl-install-update) を使用して EKS ノードを `efaEnabled` 設定にプロビジョニングすると、すべてのインターフェイスがインターフェイスタイプ `EFA` で設定され、EFA 固有のセキュリティグループが作成されて、EFA デバイスプラグインがクラスターにインストールされます。`eksctl` の使用時にデバイスごとの EFA 設定をカスタマイズする必要がある場合は、[起動テンプレート](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html)に eksctl サポートを使用することをお勧めします。 以下の例では、EFA インターフェイスを備えた `NodeClass` および起動テンプレートを設定する方法を示しています。これは、EFA トラフィックに使用するか標準の IP ベースのトラフィックに使用するかに応じて、インターフェイスをカスタマイズするのに役立ちます。各インスタンスタイプでサポートされる EFA インターフェイスの数、およびネットワーク帯域幅を最大化するための設定方法については、「*Amazon EC2 ユーザーガイド*」の「[EFA 対応インスタンスタイプのネットワーク帯域幅を最大化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html)」を参照してください。 ## EKS 自動モード EKS Auto Mode では、`NodeClass` (`eks.amazonaws.com/v1`) の `advancedNetworking.networkInterfaces` フィールドを使用して EFA ネットワークインターフェイスを設定します。各エントリでは、`networkCardIndex`、`deviceIndex`、および `interfaceType` を指定します。`interfaceType` は、標準ネットワークインターフェイスの場合は `interface` になり、RDMA トラフィック専用で IP アドレスの割り当てがない EFA インターフェイスの場合は `efa-only` になります。 `networkInterfaces` が設定されている場合、`NodeClass` を参照する `NodePool` によって起動されたインスタンスは、ポッドが `vpc.amazonaws.com/efa` リソースをリクエストするかどうかに関係なく、この設定を使用します。EKS Auto Mode は、静的ネットワークインターフェイス設定を持つノードのインスタンス起動後に、追加の IP、プレフィックス、または ENI をアタッチしません。起動時に設定されたインターフェイスと IP のみが Pod で使用できます。 この機能は、[静的キャパシティノードプール](auto-static-capacity.md)とともに使用することで、分散トレーニングおよび推論ワークロード用に事前ウォーミングされた EFA 対応ノードを維持できます。 ### P5 の EFA 専用インターフェイスを使用した EKS Auto Mode NodeClass の例 ``` apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: efa-node-class spec: role: MyNodeRole subnetSelectorTerms: - tags: Name: "private-subnet" securityGroupSelectorTerms: - tags: Name: "efa-security-group" placementGroupSelector: name: "ml-training-pg" advancedNetworking: networkInterfaces: - deviceIndex: 0 interfaceType: interface networkCardIndex: 0 secondaryIPv4PrefixCount: 1 - networkCardIndex: 0 deviceIndex: 1 interfaceType: efa-only - networkCardIndex: 1 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 2 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 3 deviceIndex: 0 interfaceType: efa-only ``` 静的ネットワークインターフェイス設定の制約の完全なリストについては、NodeClass ドキュメントの [静的ネットワークインターフェイスの設定](create-node-class.md#static-network-interfaces) を参照してください。 ## Karpenter `networkInterfaces` の各エントリで、`networkCardIndex`、`deviceIndex`、および `interfaceType` を指定します。`interfaceType` は、標準ネットワークインターフェイスの場合は `interface`、RDMA トラフィック専用で IP アドレスの割り当てがない EFA インターフェイスの場合は `efa-only` になります。`networkInterfaces` が設定されている場合、`NodeClass` を参照する `NodePool` によって起動されたインスタンスは、ポッドが `vpc.amazonaws.com/efa` リソースをリクエストするかどうかに関係なく、この設定を使用します。 `NodeClass` で `networkInterfaces` を指定せずに Karpenter を使用している場合、`vpc.amazonaws.com/efa` をリクエストするポッド用にインスタンスを作成すると、すべてのインターフェイスがインターフェイスタイプ `EFA` で設定されます。 Karpenter v1.11 で `EC2NodeClass` の `networkInterfaces` 設定が追加されました。次の例は、1 つの ENA インターフェイスと 8 つの EFA 専用インターフェイスを備えた P6-B200 インスタンス用に設定された `EC2NodeClass` を示しています。 ### EFA 専用インターフェイスを備えた P6-B200 の Karpenter EC2NodeClass の例 ``` apiVersion: karpenter.k8s.aws/v1 kind: EC2NodeClass metadata: name: efa-node-class spec: networkInterfaces: - networkCardIndex: 0 deviceIndex: 0 interfaceType: interface - networkCardIndex: 0 deviceIndex: 1 interfaceType: efa-only - networkCardIndex: 1 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 2 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 3 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 4 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 5 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 6 deviceIndex: 0 interfaceType: efa-only - networkCardIndex: 7 deviceIndex: 0 interfaceType: efa-only ``` ## EKS マネージドノードグループとセルフマネージドノード EKS マネージドノードグループまたはセルフマネージドノードでは、[起動テンプレート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)を使用して各ネットワークインターフェイスの設定を渡します。 次の例は、1 つの ENA インターフェイスと 8 つの EFA 専用インターフェイスを備えた P6-B200 インスタンス用に設定された起動テンプレートを示しています。プライマリネットワークインターフェイス (ネットワークカード 0、デバイスインデックス 0) では IP トラフィックに標準の `interface` タイプを使用し、その他のインターフェイスでは専用の RDMA トラフィックに `efa-only` を使用しています。`efa-only` インターフェイスの数は、インスタンスタイプに基づいて調整します。各インスタンスタイプでサポートされる EFA インターフェイスの数については、「*Amazon EC2 ユーザーガイド*」の「[EFA 対応インスタンスタイプのネットワーク帯域幅を最大化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html)」を参照してください。 ### EFA 専用インターフェイスを備えた P6-B200 の起動テンプレートの例 ` security-group-id ` は、実際の値に置き換えます。EFA OS バイパス機能を有効にするには、セキュリティグループで、それ自体との間のすべてのインバウンドとアウトバウンドのトラフィックを許可する必要があります。詳細については、*Amazon EC2 ユーザーガイド* の [ステップ 1: EFA 対応のセキュリティグループを準備する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-security) を参照してください。 **重要** EKS マネージドノードグループを使用する場合、起動テンプレートで `SubnetId` は指定しないでください。EKS では、すべてのサブネットを `CreateNodegroup` API で指定する必要があり、サブネットの設定を含む起動テンプレートは拒否されます。 ``` { "LaunchTemplateName": "efa-launch-template", "LaunchTemplateData": { "InstanceType": "p6-b200.48xlarge", "NetworkInterfaces": [ { "NetworkCardIndex": 0, "DeviceIndex": 0, "InterfaceType": "interface", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 0, "DeviceIndex": 1, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 1, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 2, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 3, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 4, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 5, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 6, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] }, { "NetworkCardIndex": 7, "DeviceIndex": 0, "InterfaceType": "efa-only", "Groups": ["security-group-id"] } ] } } ``` ## EKS 最適化 AMI を EFA と共に使用する EKS 最適化 AL2023 AMI とすべての Bottlerocket AMI には、EFA を使用するために必要なホストレベルのコンポーネントが含まれています。これらのコンポーネントは、具体的には [aws-efa-installer](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable) によってインストールされます。EFA DRA ドライバーまたは EFA デバイスプラグインは EKS AL2023 および Bottlerocket AMI には**含まれていない**ため、ワークロードをデプロイする前にクラスターに別途インストールする必要があります。 ## IP アドレス割り当てを節約する `p5.48xlarge` や `p6-b200.48xlarge` などの EFA 対応インスタンスは、多くのネットワークインターフェイスをサポートしています。デフォルトでは、Amazon VPC CNI は、IP 対応のすべてのアタッチされた ENI に IP アドレスを割り当てます。これにより、それらのアドレスがポッドで頻繁には使用されない場合でも、サブネットの IP アドレスが大量に消費される可能性があります。多数のネットワークインターフェイスを使用するインスタンスでは、サブネットの使用可能な IP スペースがすぐに枯渇してしまうことがあります。 EFA 対応ノードでの IP アドレスの消費を抑えるには、プライマリ以外のすべてのインターフェイスに `efa-only` を使用するようにネットワークインターフェイスを設定します。EFA 専用インターフェイスは RDMA トラフィック専用であり、IP アドレスの割り当てがないため、サブネットのアドレスを消費しません。設定例については、「[Karpenter](#eks-efa-auto-karpenter)」および「[EKS マネージドノードグループとセルフマネージドノード](#eks-efa-mng-self-managed)」を参照してください。各インスタンスタイプの推奨されるインターフェイスレイアウトについては、「*Amazon EC2 ユーザーガイド*」の「[EFA 対応インスタンスタイプのネットワーク帯域幅を最大化する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html)」を参照してください。 `efa-only` インターフェイスの使用に加えて、事前に割り当てられるウォーム IP アドレスとウォーム ENI の数を制限するように Amazon VPC CNI を設定することができます。デフォルトでは、ポッドの起動を高速化するために VPC CNI で ENI と IP アドレスのウォームプールが事前に割り当てられますが、大規模なインスタンスでは、これによって数百もの使用されない IP アドレスが予約されることがあります。`aws-node` DaemonSet で `WARM_IP_TARGET` および `WARM_ENI_TARGET` 環境変数を設定して、CNI で保持する予備の IP アドレスと ENI の数を制御します。これらの設定の詳細については、「[Amazon VPC CNI のベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview)」を参照してください。 **注記** `WARM_ENI_TARGET` および `WARM_IP_TARGET` はクラスター全体の設定であり、VPC CNI によって管理されるすべてのノードに適用されます。現在のところ、ノードグループまたはインスタンスタイプごとに異なる値を設定する方法はありません。これらの設定をより詳細に制御する必要がある場合は、GitHub の [containers-roadmap の問題 \#1834](https://github.com/aws/containers-roadmap/issues/1834) に対するフィードバックを提供してください。 ## EFA DRA ドライバー (DRANET) をインストールする EFA DRA ドライバーは、Kubernetes DRA 向けのクラウド対応ネットワークデバイス管理を提供する GitHub のアップストリーム [DRANET](https://github.com/kubernetes-sigs/dranet) プロジェクトに組み込まれています。このドキュメントでは *EFA DRA ドライバー*と *DRANET* を同じ意味で使用しており、どちらも同じツールのことを指しています。 EFA DRA ドライバーは、ドライバー名が `dra.net` で `DeviceClass` 名が `efa.networking.k8s.aws` である `ResourceSlice` オブジェクトとして EFA デバイスをアドバタイズします。EFA DRA ドライバーは、各ノードで DaemonSet として実行され、EFA デバイスを自動的に検出します。 ### 前提条件 + Amazon EKS クラスターで Kubernetes バージョン 1.34 以降を実行していて、Karpenter、EKS マネージドノードグループ、またはセルフマネージドノードグループによって静的キャパシティがプロビジョニングされていること。 + ノードのインスタンスタイプが EFA 対応の Amazon EC2 であること。サポートされるインスタンスタイプのリストについては、「*Amazon EC2 ユーザーガイド*」の「[サポートされるインスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types)」を参照してください。 + ノードに EFA 用のホストレベルのコンポーネントがインストールされていること。詳細については、「[EFA ソフトウェアをインストールする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable)」を参照してください。EKS 最適化 AL2023 NVIDIA および Neuron AMI と Bottlerocket AMI には、EFA ホストレベルのコンポーネントが含まれています。 + コマンドライン環境に Helm がインストールされていること。詳細については、「[Setup Helm instructions](helm.md)」を参照してください。 + クラスターと通信するように `kubectl` が設定されていること。詳細については、「[`kubectl` をインストールまたは更新する](install-kubectl.md#kubectl-install-update)」を参照してください。 ### 手順 **重要** EFA デバイスプラグインが実行されているノードには EFA DRA ドライバーをインストールしないでください。2 つのメカニズムを同じノードに共存させることはできません。これを行うと、基盤となるデバイスが同じノード上の複数のポッドにサイレントオーバーサブスクライブされる可能性があります。 1. EKS Helm チャートリポジトリを追加します。 ``` helm repo add eks https://aws.github.io/eks-charts ``` 1. ローカル Helm リポジトリを更新します。 ``` helm repo update ``` 1. Helm を使用してクラスターに EFA DRA ドライバーをインストールします。EFA DRA ドライバーは、インスタンスメタデータサービス (IMDS) を介して EC2 インスタンスで実行されていることを自動的に検出し、EFA デバイス検出を有効にします。EFA DRA ドライバーは、デフォルトでは `kube-system` 名前空間に DaemonSet としてデプロイされます。設定可能なパラメータについては、GitHub の [EKS Helm チャートリポジトリ](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet)にある Helm の values.yaml を参照してください。 ``` helm install aws-dranet eks/aws-dranet --namespace kube-system ``` 1. DRANET DaemonSet が実行されていることを確認します。 ``` kubectl get daemonset -n kube-system aws-dranet ``` ``` NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE aws-dranet 2 2 2 2 2 60s ``` 1. `DeviceClass` が作成されたことを確認します。 ``` kubectl get deviceclass ``` ``` NAME AGE efa.networking.k8s.aws 60s ``` 1. ノードに対して `ResourceSlice` オブジェクトがアドバタイズされていることを確認します。 ``` kubectl get resourceslices --field-selector spec.driver=dra.net ``` 上記の手順でエラーが発生する場合は、次のコマンドを使用して DRANET のログを確認できます。 ``` kubectl logs -n kube-system -l app=aws-dranet ``` 1. DRA ドライバーを使用して EFA デバイスをリクエストするには、EFA `DeviceClass` を参照する `ResourceClaim` または `ResourceClaimTemplate` を作成し、それをポッド仕様で参照します。次の例では、EFA デバイスを 1 つだけリクエストしています。 ``` apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: single-efa-claim spec: spec: devices: requests: - name: efa exactly: deviceClassName: efa.networking.k8s.aws count: 1 --- apiVersion: v1 kind: Pod metadata: name: efa-workload spec: containers: - name: app ... resources: claims: - name: efa-device resourceClaims: - name: efa-device resourceClaimTemplateName: single-efa-claim ``` ## EFA と GPU/Neuron デバイスのトポロジー認識割り当て EFA DRA ドライバーは、EFA インターフェイスを同じ PCIe ルート上の GPU または Neuron デバイスとペアリングするトポロジー認識割り当てをサポートしています。`matchAttribute` 制約を使用して、EFA と GPU または Neuron デバイスの割り当てをアライメントします。この機能を使用するには、NVIDIA または Neuron DRA ドライバーも使用する必要があります。詳細については、「[Amazon EKS で NVIDIA GPU を管理する](device-management-nvidia.md)」および「[Amazon EKS で Neuron デバイスを管理する](device-management-neuron.md)」を参照してください。 次の例では、1 つの NVIDIA GPU とアライメントされた 1 つの EFA インターフェイスをリクエストしています。 ``` apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: aligned-efa-nvidia spec: spec: devices: requests: - name: 1-efa exactly: deviceClassName: efa.networking.k8s.aws count: 1 - name: 1-gpu exactly: deviceClassName: gpu.nvidia.com count: 1 constraints: - requests: ["1-gpu", "1-efa"] matchAttribute: "resource.kubernetes.io/pcieRoot" ``` 次の例では、4 つの Neuron デバイスとアライメントされた 4 つの EFA インターフェイスをリクエストしています。 ``` apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: aligned-efa-neuron spec: spec: devices: requests: - name: 4-neurons exactly: deviceClassName: neuron.aws.com count: 4 - name: 4-efas exactly: deviceClassName: efa.networking.k8s.aws count: 4 constraints: - requests: ["4-neurons", "4-efas"] matchAttribute: "resource.aws.com/devicegroup4_id" ``` `devicegroup` 属性の名前に含まれる数字は、接続されたトポロジーグループ内の Neuron デバイスの数に対応しています。例えば、`resource.aws.com/devicegroup1_id` は単一の Neuron デバイスを識別し、`resource.aws.com/devicegroup4_id` は接続された 4 台のデバイスのグループを識別し、`resource.aws.com/devicegroup8_id` と `resource.aws.com/devicegroup16_id` は接続された 8 台と 16 台のデバイスのグループをそれぞれ識別します。割り当てられた Neuron デバイスと EFA インターフェイスが同じ接続トポロジーグループに属するように、リクエスト内のデバイスの `count` に一致する `matchAttribute` を選択します。これらの属性の詳細については、[Neuron DRA ドライバーのドキュメント](https://awsdocs-neuron.readthedocs-hosted.com/en/latest/containers/neuron-dra.html)を参照してください。 `allocationMode` を使用して、EFA デバイスをアライメントされた GPU または Neuron アクセラレーターに割り当てる方法を簡素化できます。`allocationMode` フィールドでは 2 つの値がサポートされます。`ExactCount` (デフォルト) は `count` で指定された特定の数のデバイスをリクエストし、`All` はプール内のすべての一致するデバイスをリクエストします。例えば、`p5.48xlarge` インスタンスには、1 つの GPU で同じ PCIe ルートを共有する 4 つの EFA デバイスがあります。これらの EFA デバイスのグループをアライメントされた GPU で割り当てる場合、正確な EFA-GPU デバイスマッピングやアライメントされた EFA デバイスの数がわからなくても、`ResourceClaimTemplate` で EFA デバイスに `allocationMode: All` を設定することができます。 ``` apiVersion: resource.k8s.io/v1 kind: ResourceClaimTemplate metadata: name: aligned-all-efa-one-nvidia spec: spec: devices: requests: - name: all-efas exactly: deviceClassName: efa.networking.k8s.aws allocationMode: All - name: one-gpu exactly: deviceClassName: gpu.nvidia.com allocationMode: ExactCount count: 1 constraints: - requests: ["all-efas", "one-gpu"] matchAttribute: "resource.kubernetes.io/pcieRoot" ``` ## 複数のポッド間で EFA デバイスを共有する EFA DRA ドライバーは、`ResourceClaim` を使用して複数のポッド間での EFA デバイスの共有をサポートします。ポッドごとに個別のクレームを生成する `ResourceClaimTemplate` とは異なり、`ResourceClaim` は、個別に作成して複数のポッドから参照する名前付きオブジェクトです。同じ `ResourceClaim` を参照するすべてのポッドで、割り当てられた同じ EFA デバイスへのアクセスを共有し、それらのデバイスが使用可能な同じノードにスケジュールされます。 ポッド間で EFA デバイスを共有するには、EFA デバイスをリクエストする `ResourceClaim` を作成し、そのクレームを各ポッドの `resourceClaims` フィールドで `resourceClaimName` を使用して名前で参照します。`ResourceClaim` は、それを参照するポッドの作成前にクラスターに存在している必要があります。参照している `ResourceClaim` が存在しない場合、ポッドはクレームが作成されるまで保留状態になります。 次の例では、4 つの EFA デバイスをリクエストする `ResourceClaim` と、それらのデバイスへのアクセスを共有する 2 つのポッドを作成します。 1. `ResourceClaim` を作成します。 ``` apiVersion: resource.k8s.io/v1 kind: ResourceClaim metadata: name: shared-efa spec: devices: requests: - name: efa exactly: deviceClassName: efa.networking.k8s.aws count: 4 ``` 1. EFA デバイスにアクセスする必要がある各ポッドで `ResourceClaim` を名前で参照します。各ポッドで、`resourceClaimTemplateName` ではなく `resourceClaimName` を使用して既存のクレームを参照します。 ``` apiVersion: v1 kind: Pod metadata: name: training-worker spec: containers: - name: worker image: my-training-image resources: claims: - name: efa-devices resourceClaims: - name: efa-devices resourceClaimName: shared-efa --- apiVersion: v1 kind: Pod metadata: name: training-monitor spec: containers: - name: monitor image: my-monitor-image resources: claims: - name: efa-devices resourceClaims: - name: efa-devices resourceClaimName: shared-efa ``` 両方のポッドが同じ `shared-efa` `ResourceClaim` を参照し、それらの EFA デバイスが割り当てられたノードにスケジュールされます。`ResourceClaim` のライフサイクルはポッドとは無関係です。このクレームは、それを参照するすべてのポッドが削除されても、削除するまで保持されます。 ## EFA Kubernetes デバイスプラグインをインストールする EFA Kubernetes デバイスプラグインは、EFA デバイスを `vpc.amazonaws.com/efa` 拡張リソースとしてアドバタイズします。コンテナリソースのリクエストや制限の際に EFA デバイスをリクエストします。トレーニングワークロードで EFA を設定する詳細なチュートリアルについては、「[Elastic Fabric Adapter を使用して Amazon EKS で機械学習トレーニングを実行する](node-efa.md)」を参照してください。 **重要** EKS 最適化 AL2023 高速 AMI を使用している場合、EFA インターフェイスを備えた NVIDIA GPU または Neuron デバイスのトポロジーに沿った割り当てが自動的に行われます。この自動アライメントは、Bottlerocket EKS 最適化 AMI またはカスタム AMI を使用している場合は発生しません。Bottlerocket またはカスタム AMI でトポロジーに沿ったアクセラレーターと EFA デバイスの割り当てが必要な場合は、EFA DRA ドライバーと対応する Neuron DRA ドライバーを使用してください。Bottlerocket で NVIDIA DRA ドライバーを使用するには、まず Bottlerocket NVIDIA バリアントにバンドルされている NVIDIA デバイスプラグインを無効にする必要があります。これには Bottlerocket バージョン 1.63.0 以降が必要です。詳細については、「[EFA と GPU/Neuron デバイスのトポロジー認識割り当て](#efa-dra-topology-aware)」および「[NVIDIA DRA ドライバーをインストールする](device-management-nvidia-dra-device-plugin.md#eks-nvidia-dra-driver)」を参照してください。 **重要** NVIDIA `k8s-device-plugin` v0.19.0 以降では、`--mofed-enabled` フラグがデフォルトで `true` に設定されています。そのため、NVIDIA デバイスプラグインでは、GPU をリクエストするコンテナにすべての `/dev/infiniband/uverbs*` デバイスがマウントされます。これは、`/dev/infiniband` で EFA デバイスの割り当てを管理するコンポーネントである EFA デバイスプラグインと競合します。NVIDIA デバイスプラグインで EKS マネージドノードグループまたはセルフマネージドノードを使用している場合は、MOFED を明示的に無効にする必要があります。手順については、「[NVIDIA Kubernetes デバイスプラグインをインストールする](device-management-nvidia-dra-device-plugin.md#eks-nvidia-device-plugin)」を参照してください。 EKS オードモードではデフォルトで MOFED が有効にならないため、この問題は影響しません。 ### 前提条件 + Amazon EKS クラスター。 + ノードのインスタンスタイプが EFA 対応の Amazon EC2 であること。サポートされるインスタンスタイプのリストについては、「*Amazon EC2 ユーザーガイド*」の「[サポートされるインスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html#efa-instance-types)」を参照してください。 + ノードに EFA 用のホストレベルのコンポーネントがインストールされていること。詳細については、「[EFA ソフトウェアをインストールする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable)」を参照してください。EKS 最適化 AL2023 AMI と Bottlerocket AMI には、EFA ホストレベルのコンポーネントが含まれています。 + コマンドライン環境に Helm がインストールされていること。詳細については、「[Setup Helm instructions](helm.md)」を参照してください。 + クラスターと通信するように `kubectl` が設定されていること。詳細については、「[`kubectl` をインストールまたは更新する](install-kubectl.md#kubectl-install-update)」を参照してください。 ### 手順 1. EKS Helm チャートリポジトリを追加します。 ``` helm repo add eks https://aws.github.io/eks-charts ``` 1. ローカル Helm リポジトリを更新します。 ``` helm repo update ``` 1. EFA デバイスプラグインをインストールします。 ``` helm install efa eks/aws-efa-k8s-device-plugin -n kube-system ``` 1. DaemonSet という EFA デバイスプラグインが実行されていることを確認します。 ``` kubectl get daemonset -n kube-system efa-aws-efa-k8s-device-plugin ``` ``` NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE efa-aws-efa-k8s-device-plugin 2 2 2 2 2 60s ``` 1. ノードを調べて割り当て可能な EFA リソースがあることを確認します。 ``` kubectl get nodes "-o=custom-columns=NAME:.metadata.name,EFA:.status.allocatable.vpc\.amazonaws\.com/efa" ``` ``` NAME EFA ip-192-168-11-225.us-west-2.compute.internal 4 ip-192-168-24-96.us-west-2.compute.internal 4 ``` 1. デバイスプラグインを使用して EFA デバイスをリクエストするには、コンテナリソースのリクエストと制限で `vpc.amazonaws.com/efa` リソースを指定します。 ``` apiVersion: v1 kind: Pod metadata: name: efa-workload spec: containers: - name: app ... resources: limits: vpc.amazonaws.com/efa: 4 hugepages-2Mi: ... requests: vpc.amazonaws.com/efa: 4 hugepages-2Mi: ... ```