**이 페이지 개선에 도움 주기**
이 사용자 가이드에 기여하려면 모든 페이지의 오른쪽 창에 있는 **GitHub에서 이 페이지 편집** 링크를 선택합니다.
# Amazon EKS에서 EFA 디바이스 관리
[Elastic Fabric Adapter](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa.html)(EFA)는 인공 지능, 기계 학습 및 고성능 컴퓨팅(HPC) 워크로드를 위한 고성능 노드 간 통신 및 원격 직접 메모리 액세스(RDMA)를 지원하는 Amazon EC2 인스턴스용 네트워크 디바이스입니다. Amazon EKS는 EKS 클러스터에서 EFA 디바이스를 관리하기 위한 두 가지 메커니즘(*EFA 동적 리소스 할당(DRA) 드라이버(DRANET)* 및 *EFA 디바이스 플러그인*)을 지원합니다.
EKS 관리형 노드 그룹 또는 자체 관리형 노드 그룹과 함께 Kubernetes 버전 1.34 이상을 실행하는 EKS 클러스터의 새 배포에 대해 EFA DRA 드라이버(DRANET)를 사용하는 것이 좋습니다. EFA DRA 드라이버를 사용하면 EFA 인터페이스를 토폴로지상 로컬 GPU 또는 Neuron 디바이스와 페어링하는 토폴로지 인식 할당을 구성할 수 있으며, 이를 통해 포드 간 디바이스 공유를 지원합니다.
EFA DRA 드라이버는 Karpenter 또는 EKS 자율 모드에서 지원되지 않습니다. Karpenter 및 EKS 자율 모드에서 [EFA 디바이스 플러그인](#eks-efa-device-plugin)을 사용합니다. 또한 EFA 디바이스 플러그인은 EKS 관리형 노드 그룹 및 자체 관리형 노드에 대해서도 계속 지원됩니다.
## EFA DRA 드라이버 및 EFA 디바이스 플러그인 비교
| 기능 | EFA DRA 드라이버 | EFA 디바이스 플러그인 |
| --- | --- | --- |
| 최소 Kubernetes 버전 | 1.34 | 모든 EKS 지원 Kubernetes 버전 |
| EKS 컴퓨팅 | 관리형 노드 그룹, 자체 관리형 노드 | EKS 자율 모드, Karpenter, 관리형 노드 그룹, 자체 관리형 노드 |
| EKS 최적화 AMI | AL2023(NVIDIA, Neuron), Bottlerocket | AL2023(NVIDIA, Neuron), Bottlerocket |
| 디바이스 알림 | 디바이스 유형, 토폴로지, PCle 지역성을 포함한 `ResourceSlice` 객체를 통한 다양한 속성 | `vpc.amazonaws.com/efa` 확장 리소스 수(정수) |
| GPU-EFA 선호도 | DRA 네이티브 토폴로지 인식 | 자동 토폴로지 인식(EKS 최적화 AL2023 AMI만 해당) |
| Neuron-EFA 친화도 | DRA 네이티브 토폴로지 인식 | 자동 토폴로지 인식(EKS 최적화 AL2023 AMI만 해당) |
| 디바이스 공유 | 여러 포드가 공유 `ResourceClaim` 참조를 통해 동일한 EFA 디바이스를 공유할 수 있음 | 지원되지 않음. 각 EFA 디바이스는 하나의 포드에만 할당됩니다. |
## EFA 인터페이스를 사용하여 EKS 노드 생성
EFA 인터페이스를 사용하여 EKS 노드를 생성하는 경우 인스턴스 프로비저닝 중에 EFA 인터페이스가 인스턴스에 연결됩니다. 디바이스별 EFA 구성을 사용자 지정하고 Karpenter, EKS 관리형 노드 그룹 또는 EKS 자체 관리형 노드 그룹과 함께 [플레이스먼트 그룹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html)을 사용할 수 있습니다. Karpenter를 사용하면 `NodeClass`를 통해 각 네트워크 인터페이스에 대한 구성을 전달합니다. EKS 관리형 노드 그룹 또는 자체 관리형 노드를 사용하면 [시작 템플릿](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-templates.html)을 사용하여 각 네트워크 인터페이스에 대한 구성을 전달합니다. 디바이스별 EFA 구성 및 플레이스먼트 그룹에 대한 EKS 자율 모드 지원은 곧 제공될 예정입니다.
`efaEnabled` 설정으로 EKS 노드를 프로비저닝하기 위해 [`eksctl`](install-kubectl.md#eksctl-install-update)을 사용하는 경우 모든 인터페이스가 `EFA` 인터페이스 유형으로 구성되고, EFA별 보안 그룹이 생성되며, EFA 디바이스 플러그인이 클러스터에 설치됩니다. `eksctl`을 사용할 때 디바이스별 EFA 구성을 사용자 지정해야 하는 경우 [시작 템플릿](https://docs.aws.amazon.com/eks/latest/eksctl/launch-template-support.html)에 대한 'eksctl'의 지원을 사용하는 것이 좋습니다.
다음 예제에서는 EFA 인터페이스를 사용하여 `NodeClass`를 구성하고 템플릿을 시작하는 방법을 보여줍니다. 표준 IP 기반 트래픽과 비교하여 EFA에 사용되는 인터페이스를 사용자 지정하는 데 유용합니다. 각 인스턴스 유형에서 지원하는 EFA 인터페이스 수와 최대 네트워크 대역폭에 맞게 구성하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [EFA 지원 인스턴스 유형에 대한 네트워크 대역폭 최대화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-acc-inst-types.html)를 참조하세요.
## Karpenter
`networkInterfaces`의 각 항목에서는 `networkCardIndex`, `deviceIndex` 및 `interfaceType`을 지정합니다. `interfaceType`은 표준 네트워크 인터페이스에 대해 `interface` 또는 RDMA 트래픽 전용이고 IP 주소가 할당되지 않은 EFA 인터페이스에 대해 `efa-only`일 수 있습니다. `networkInterfaces`가 구성된 경우 포드가 `vpc.amazonaws.com/efa` 리소스를 요청하는지에 관계없이 `NodeClass`를 참조하는 `NodePool`에서 시작된 인스턴스는 이 구성을 사용합니다.
`NodeClass`에서 `networkInterfaces`를 지정하지 않고 Karpenter를 사용하는 경우 `vpc.amazonaws.com/efa`를 요청하는 포드에 대해 생성된 인스턴스에서는 모든 인터페이스가 `EFA`의 인터페이스 유형으로 구성됩니다.
`EC2NodeClass`에 대한 `networkInterfaces` 구성이 Karpenter v1.11에 추가되었습니다. 다음 예제에서는 1개의 ENA 인터페이스와 8개의 EFA 전용 인터페이스를 포함하여 P6-B200 인스턴스에 대해 구성된 `EC2NodeClass`를 보여줍니다.
### P6-B200에 대해 EFA 전용 인터페이스를 포함하는 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)를 참조하세요.
### P6-B200에 대해 EFA 전용 인터페이스를 포함하는 시작 템플릿 예제
` 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"]
}
]
}
}
```
## EFA에서 EKS 최적화 AMI 사용
EKS 최적화 AL2023 가속 AMI(NVIDIA 및 Neuron) 그리고 모든 Bottlerocket AMI에는 EFA를 사용해야 하는 호스트 수준 구성 요소(특히, [aws-efa-installer](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/efa-start.html#efa-start-enable)에 의해 설치된 구성 요소)가 포함되어 있습니다. EKS AL2023 및 Bottlerocket AMI에는 EFA DRA 드라이버 또는 EFA 디바이스 플러그인이 **포함되어 있지 않으므로**, 워크로드를 배포하기 전에 해당 디바이스 플러그인을 클러스터에 별도로 설치해야 합니다.
## 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에서 유지 관리하는 ENI 및 예비 IP 주소 수를 제어합니다. 이러한 설정에 대한 자세한 내용은 [Amazon VPC CNI 모범 사례](https://docs.aws.amazon.com/eks/latest/best-practices/vpc-cni.html#_overview)를 참조하세요.
**참고**
`WARM_ENI_TARGET` 및 `WARM_IP_TARGET` 설정은 클러스터 전체에 적용되며, VPC CNI에서 관리하는 모든 노드에 적용됩니다. 현재 노드 그룹 또는 인스턴스 유형별로 다른 값을 설정하는 방법은 없습니다. 이러한 설정을 더 세밀하게 제어해야 하는 경우 [containers-roadmap issue \#1834](https://github.com/aws/containers-roadmap/issues/1834)에 대한 피드백을 제공합니다.
## EFA DRA 드라이버 설치(DRANET)
EFA DRA 드라이버는 Kubernetes DRA에 대한 클라우드 인식 네트워크 디바이스 관리를 제공하는 업스트림 [DRANET](https://github.com/kubernetes-sigs/dranet) 프로젝트에 구축되어 있습니다. *EFA DRA 드라이버* 및 *DRANET*은 이 설명서 전체에서 상호 교환적으로 사용되며 동일한 도구를 참조합니다.
EFA DRA 드라이버는 EFA 디바이스를 드라이버 이름이 `dra.net`이고 `DeviceClass` 이름이 `efa.networking.k8s.aws`인 `ResourceSlice` 객체로 알립니다. EFA DRA 드라이버는 각 노드에서 DaemonSet로 실행되며 EFA 디바이스를 자동으로 검색합니다.
### 사전 조건
+ EKS 관리형 노드 그룹 또는 자체 관리형 노드 그룹을 사용하여 Kubernetes 버전 1.34 이상을 실행하는 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 NVIDIA 및 Neuron AMI 그리고 Bottlerocket AMI에는 EFA 호스트 수준 구성 요소가 포함되어 있습니다.
+ 명령줄 환경에 설치된 Helm에 대한 자세한 내용은 [Helm 설정 지침](helm.md)을 참조하세요.
+ 클러스터와 통신하도록 구성된 `kubectl`. 자세한 내용은 [`kubectl` 설치 또는 업데이트](install-kubectl.md#kubectl-install-update) 섹션을 참조하세요.
### 절차
**중요**
EFA 디바이스 플러그인이 실행 중인 노드에 EFA DRA 드라이버를 설치하지 마세요. 두 메커니즘은 동일한 노드에 공존할 수 없습니다. 업데이트는 업스트림 Kubernetes [KEP-5004](https://github.com/kubernetes/enhancements/issues/5004)를 참조하세요.
1. EKS 헬름 차트 리포지토리를 추가하세요.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. 로컬 헬름 리포지토리를 업데이트하세요.
```
helm repo update
```
1. 헬름을 사용하여 클러스터에 EFA DRA 드라이버를 설치하세요. EFA DRA 드라이버는 인스턴스 메타데이터 서비스(IMDS)를 통해 EC2 인스턴스에서 실행되고 있음을 자동으로 감지하고 EFA 디바이스 검색을 활성화합니다. EFA DRA 드라이버는 기본적으로 `kube-system` 네임스페이스를 사용하여 DaemonSet로 배포됩니다. 구성 가능한 파라미터는 [EKS 헬름 차트 GitHub 리포지토리](https://github.com/aws/eks-charts/tree/master/stable/aws-dranet)에서 헬름 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 디바이스를 요청합니다.
```
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)(을)를 참조하세요.
다음 예제에서는 NVIDIA GPU 1개에 맞게 정렬된 EFA 인터페이스 1개를 요청합니다.
```
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"
```
다음 예제에서는 Neuron 디바이스 4개에 맞게 정렬된 EFA 인터페이스 4개를 요청합니다.
```
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`를 사용하여 정렬된 GPU 또는 Neuron 액셀러레이터에 EFA 디바이스를 할당하는 방법을 단순화할 수 있습니다. `allocationMode` 필드는 두 가지 값을 지원합니다. `ExactCount`(기본값)는 `count`에서 지정한 특정 수의 디바이스를 요청하고, `All`은 풀에서 일치하는 모든 디바이스를 요청합니다. 예를 들어 `p5.48xlarge` 인스턴스에는 하나의 GPU와 동일한 PCIe 루트를 공유하는 4개의 EFA 디바이스가 있습니다. 정확한 EFA-GPU 디바이스 매핑과 정렬된 EFA 디바이스 수를 모르는 경우에도 정렬된 GPU를 포함하는 이러한 EFA 디바이스 그룹을 할당하려면 EFA 디바이스에 대해 `ResourceClaimTemplate`을 `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`을 생성한 후 `resourceClaimName`을 사용하여 각 포드의 `resourceClaims` 필드에서 이름으로 해당 클레임을 참조합니다. `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) 섹션을 참조하세요.
**중요**
EFA 인터페이스를 사용하는 NVIDIA GPU 또는 Neuron 디바이스의 토폴로지 정렬 할당은 EKS 최적화 AL2023 가속 AMI를 사용할 때 자동으로 수행됩니다. Bottlerocket EKS 최적화 AMI 또는 사용자 지정 AMI를 사용할 때 이 자동 정렬은 수행되지 않습니다. Bottlerocket 또는 사용자 지정 AMI를 사용하는 토폴로지 정렬 액셀러레이터 및 EFA 디바이스 할당이 필요한 경우 EFA DRA 드라이버 및 해당 Neuron DRA 드라이버를 사용합니다. NVIDIA DRA 드라이버는 Bottlerocket에서 지원되지 않습니다. 자세한 내용은 [토폴로지 인식 EFA 및 GPU/Neuron 디바이스 할당](#efa-dra-topology-aware) 섹션을 참조하세요.
**중요**
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.md#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 NVIDIA 및 Neuron AMI 그리고 Bottlerocket AMI에는 EFA 호스트 수준 구성 요소가 포함되어 있습니다.
+ 명령줄 환경에 설치된 Helm에 대한 자세한 내용은 [Helm 설정 지침](helm.md)을 참조하세요.
+ 클러스터와 통신하도록 구성된 `kubectl`. 자세한 내용은 [`kubectl` 설치 또는 업데이트](install-kubectl.md#kubectl-install-update) 섹션을 참조하세요.
### 절차
1. EKS 헬름 차트 리포지토리를 추가하세요.
```
helm repo add eks https://aws.github.io/eks-charts
```
1. 로컬 헬름 리포지토리를 업데이트하세요.
```
helm repo update
```
1. EFA 디바이스 플러그인을 설치하세요.
```
helm install efa eks/aws-efa-k8s-device-plugin -n kube-system
```
1. EFA 디바이스 플러그인 DaemonSet가 실행 중인지 확인하세요.
```
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: ...
```