Amazon EKS에서 EFA 장치 관리하기

Amazon EKS에서 EFA 장치 관리하기

Elastic Fabric Adapter (EFA)는 인공지능, 머신러닝, High Performance Computing (HPC) 워크로드를 위한 고성능 노드 간 통신과 RDMA (Remote Direct Memory Access)를 가능하게 하는 Amazon EC2 인스턴스용 네트워크 장치입니다. Amazon EKS는 EKS 클러스터에서 EFA 장치를 관리하기 위한 두 가지 메커니즘을 지원합니다. EFA Dynamic Resource Allocation (DRA) driver (DRANET)와 EFA device plugin이에요.

Kubernetes 1.34 이상 버전에서 Karpenter의 정적 용량 프로비저닝, EKS 관리형 노드 그룹, 또는 자체 관리 노드를 사용하는 새 배포에는 DRA 드라이버를 사용할 것을 권장합니다. DRA는 현재 EKS Auto Mode에서 지원되지 않아요. EFA DRA driver로 EFA 인터페이스를 토폴로지상 로컬인 GPU 또는 Neuron 장치와 짝짓는 토폴로지 인식 할당을 구성하고 Pod 간에 장치를 공유할 수 있습니다.

EFA DRA driver vs EFA device plugin

기능 EFA DRA driver EFA device plugin
최소 Kubernetes 버전 1.34 모든 EKS 지원 Kubernetes 버전
EKS 컴퓨팅 Karpenter (정적 용량만), 관리형 노드 그룹, 자체 관리 노드 EKS Auto Mode, 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 참조로 여러 Pod가 같은 EFA 장치 공유 가능 미지원. 각 EFA 장치는 한 Pod에 독점 할당

EFA 인터페이스로 EKS 노드 생성

EFA 인터페이스로 EKS 노드를 만들면 EFA 인터페이스가 인스턴스 프로비저닝 중에 인스턴스에 연결됩니다. EKS Auto Mode, Karpenter, EKS 관리형 노드 그룹, EKS 자체 관리 노드 그룹에서 장치별 EFA 구성을 사용자 정의하고 배치 그룹을 사용할 수 있어요. EKS Auto Mode에서는 NodeClass의 advancedNetworking.networkInterfaces 아래에서 각 네트워크 인터페이스 구성을 전달합니다. Karpenter에서는 EC2NodeClass를 통해 각 네트워크 인터페이스 구성을 전달합니다. EKS 관리형 노드 그룹이나 자체 관리 노드에서는 런치 템플릿으로 각 네트워크 인터페이스 구성을 전달해요.

efaEnabled 설정으로 EKS 노드를 프로비저닝할 때 eksctl을 사용하면 모든 인터페이스가 EFA 인터페이스 유형으로 구성되고, EFA 전용 보안 그룹이 생성되며, EFA device plugin이 클러스터에 설치되어요. eksctl을 사용할 때 장치별 EFA 구성을 사용자 정의해야 한다면 eksctl의 런치 템플릿 지원을 사용하는 것이 좋습니다.

다음 예시는 EFA 인터페이스로 NodeClass와 런치 템플릿을 구성하는 방법을 보여줍니다. 이는 EFA용 인터페이스와 표준 IP 기반 트래픽용 인터페이스를 사용자 정의하는 데 유용해요. 각 인스턴스 유형이 지원하는 EFA 인터페이스 수와 최대 네트워크 대역폭을 위한 구성 방법은 Amazon EC2 User Guide의 Maximize network bandwidth for EFA-enabled instance types를 참고하세요.

EKS Auto Mode

EKS Auto Mode에서는 NodeClass (eks.amazonaws.com/v1)의 advancedNetworking.networkInterfaces 필드를 사용해서 EFA 네트워크 인터페이스를 구성합니다. 각 항목은 networkCardIndex, deviceIndex, interfaceType을 지정해요. interfaceType은 표준 네트워크 인터페이스용 interface이거나, IP 주소가 할당되지 않고 RDMA 트래픽 전용인 EFA 인터페이스용 efa-only일 수 있습니다.

networkInterfaces가 구성되면 NodeClass를 참조하는 NodePool이 시작하는 인스턴스는 Pod가 vpc.amazonaws.com/efa 리소스를 요청하는지와 무관하게 이 구성을 사용해요. EKS Auto Mode는 정적 네트워크 인터페이스 구성을 가진 노드에 대해 인스턴스 시작 후 추가 IP, 프리픽스, ENI를 연결하지 않습니다. 시작 시 구성된 인터페이스와 IP만 Pod에 사용할 수 있어요.

이 기능은 정적 용량 노드 풀과 함께 사용해서 분산 학습·추론 워크로드를 위한 사전 워밍(pre-warmed)되고 EFA 준비된 노드를 유지할 수 있습니다.

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 문서의 Static Network Interface Configuration을 참고하세요.

Karpenter

networkInterfaces의 각 항목은 networkCardIndex, deviceIndex, interfaceType을 지정합니다. interfaceType은 표준 네트워크 인터페이스용 interface이거나, IP 주소가 없고 RDMA 트래픽 전용인 EFA 인터페이스용 efa-only일 수 있어요. networkInterfaces가 구성되면 NodeClass를 참조하는 NodePool이 시작하는 인스턴스는 Pod가 vpc.amazonaws.com/efa 리소스를 요청하는지와 무관하게 이 구성을 사용합니다.

NodeClass에서 networkInterfaces를 지정하지 않고 Karpenter를 사용하면 vpc.amazonaws.com/efa를 요청하는 Pod용으로 생성된 인스턴스는 모든 인터페이스가 EFA 인터페이스 유형으로 구성돼요.

EC2NodeClass의 networkInterfaces 구성은 Karpenter v1.11에서 추가되었습니다. 다음 예시는 1개의 ENA 인터페이스와 8개의 EFA-only 인터페이스로 구성된 P6-B200 인스턴스용 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 관리형 노드 그룹이나 자체 관리 노드에서는 런치 템플릿으로 각 네트워크 인터페이스 구성을 전달해요.

다음 예시는 1개의 ENA 인터페이스와 8개의 EFA-only 인터페이스로 구성된 P6-B200 인스턴스용 런치 템플릿을 보여줍니다. 기본 네트워크 인터페이스(네트워크 카드 0, device index 0)는 IP 트래픽용 표준 interface 유형을 사용하고, 추가 인터페이스는 전용 RDMA 트래픽용 efa-only를 사용해요. 인스턴스 유형에 따라 efa-only 인터페이스 수를 조정하세요. 각 인스턴스 유형이 지원하는 EFA 인터페이스 수는 Amazon EC2 User Guide의 Maximize network bandwidth for EFA-enabled instance types를 참고하세요.

security-group-id를 자신의 값으로 바꾸세요. 보안 그룹은 EFA OS 바이패스 기능을 활성화하려면 자신으로 들어오고 나가는 모든 인바운드·아웃바운드 트래픽을 허용해야 해요. 자세한 내용은 Amazon EC2 User Guide의 Step 1: Prepare an EFA-enabled security group을 참고하세요.

중요

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가 설치하는 구성 요소를 포함합니다. EKS AL2023 및 Bottlerocket AMI에는 EFA DRA driver나 EFA device plugin이 포함되어 있지 않으므로, 워크로드를 배포하기 전에 클러스터에 별도로 설치해야 해요.

IP 주소 할당 절약

p5.48xlarge와 p6-b200.48xlarge 같은 EFA 지원 인스턴스는 많은 네트워크 인터페이스를 지원합니다. 기본적으로 Amazon VPC CNI는 IP 사용 가능한 연결된 모든 ENI에 걸쳐 IP 주소를 할당하는데, 이는 주소가 Pod에 활발히 사용되지 않더라도 서브넷에서 많은 수의 IP 주소를 소비할 수 있어요. 수십 개의 네트워크 인터페이스가 있는 인스턴스에서는 이로 인해 서브넷의 사용 가능한 IP 공간이 빠르게 고갈될 수 있습니다.

EFA 지원 노드에서 IP 주소 소비를 줄이려면 기본 인터페이스를 제외한 모든 인터페이스에 efa-only를 사용하도록 네트워크 인터페이스를 구성하세요. EFA-only 인터페이스는 RDMA 트래픽 전용이며 IP 주소가 할당되지 않으므로 서브넷의 주소를 소비하지 않습니다. 예시 구성은 Karpenter 및 EKS managed node groups and self-managed nodes를 참고하세요. 각 인스턴스 유형에 대한 권장 인터페이스 레이아웃은 Amazon EC2 User Guide의 Maximize network bandwidth for EFA-enabled instance types를 참고하세요.

efa-only 인터페이스를 사용하는 것에 더해, Amazon VPC CNI를 구성해서 워밍(사전 할당) IP 주소와 ENI의 수를 제한할 수 있어요. 기본적으로 VPC CNI는 빠른 Pod 시작을 위해 ENI와 IP 주소의 워밍 풀을 사전 할당하지만, 대형 인스턴스에서는 이로 인해 수백 개의 미사용 IP 주소가 예약될 수 있습니다. aws-node DaemonSet의 WARM_IP_TARGET과 WARM_ENI_TARGET 환경 변수를 설정해서 CNI가 유지할 여분 IP 주소와 ENI 수를 제어하세요. 이 설정에 대한 자세한 내용은 Amazon VPC CNI best practices를 참고하세요.

참고

WARM_ENI_TARGET과 WARM_IP_TARGET 설정은 클러스터 전역이며 VPC CNI가 관리하는 모든 노드에 적용됩니다. 현재 노드 그룹이나 인스턴스 유형별로 다른 값을 설정할 방법은 없어요. 이 설정을 더 세밀하게 제어해야 한다면 GitHub의 containers-roadmap issue #1834에 피드백을 제공하세요.

EFA DRA driver (DRANET) 설치

EFA DRA driver는 Kubernetes DRA를 위한 클라우드 인식 네트워크 장치 관리를 제공하는 GitHub의 업스트림 DRANET 프로젝트에 내장되어 있어요. 이 문서 전반에서 EFA DRA driver와 DRANET은 서로 바꿔 쓸 수 있고 같은 도구를 가리킵니다.

EFA DRA driver는 EFA 장치를 드라이버 이름 dra.net과 DeviceClass 이름 efa.networking.k8s.aws의 ResourceSlice 객체로 광고합니다. EFA DRA driver는 각 노드에서 DaemonSet으로 실행되며 EFA 장치를 자동으로 발견합니다.

사전 조건

  • Karpenter, EKS 관리형 노드 그룹, 또는 자체 관리 노드 그룹으로 정적 용량이 프로비저닝된 Kubernetes 1.34 이상을 실행하는 Amazon EKS 클러스터.
  • EFA 지원 Amazon EC2 인스턴스 유형의 노드. 지원되는 인스턴스 유형 목록은 Amazon EC2 User Guide의 Supported instance types를 참고하세요.
  • EFA용 호스트 수준 구성 요소가 설치된 노드. 자세한 내용은 Install the EFA software를 참고하세요. EKS 최적화 AL2023 NVIDIA 및 Neuron AMI와 Bottlerocket AMI는 EFA 호스트 수준 구성 요소를 포함합니다.
  • 명령줄 환경에 Helm 설치. 자세한 내용은 Setup Helm 지침을 참고하세요.
  • 클러스터와 통신하도록 구성된 kubectl. 자세한 내용은 Install or update kubectl을 참고하세요.

절차

중요

EFA device plugin이 실행 중인 노드에 EFA DRA driver를 설치하지 마세요. 두 메커니즘은 같은 노드에 공존할 수 없습니다. 그렇게 하면 기본 장치가 같은 노드의 여러 Pod에 조용히 과다 예약될 수 있어요.

EKS Helm chart 저장소를 추가합니다.

helm repo add eks https://aws.github.io/eks-charts

로컬 Helm 저장소를 업데이트합니다.

helm repo update

Helm을 사용해서 클러스터에 EFA DRA driver를 설치합니다. EFA DRA driver는 Instance Metadata Service (IMDS)를 통해 EC2 인스턴스에서 실행 중임을 자동으로 감지하고 EFA 장치 발견을 활성화해요. EFA DRA driver는 기본적으로 kube-system 네임스페이스에 DaemonSet으로 배포됩니다. 구성 가능한 파라미터는 GitHub의 EKS Helm chart 저장소에 있는 Helm values.yaml을 참고하세요.

helm install aws-dranet eks/aws-dranet --namespace kube-system

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

DeviceClass가 생성되었는지 확인합니다.

kubectl get deviceclass

NAME                    AGE
efa.networking.k8s.aws  60s

노드에 ResourceSlice 객체가 광고되는지 확인합니다.

kubectl get resourceslices --field-selector spec.driver=dra.net

위 단계에서 오류가 발생하면 다음 명령으로 DRANET 로그를 확인할 수 있어요.

kubectl logs -n kube-system -l app=aws-dranet

DRA driver를 사용해서 EFA 장치를 요청하려면 EFA DeviceClass를 참조하는 ResourceClaim 또는 ResourceClaimTemplate을 만들고 Pod 사양에서 이를 참조합니다. 다음 예제는 단일 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 driver는 같은 PCIe 루트의 GPU 또는 Neuron 장치와 EFA 인터페이스를 짝짓는 토폴로지 인식 할당을 지원합니다. matchAttribute 제약을 사용해서 EFA와 GPU 또는 Neuron 장치 할당을 정렬해요. 이 기능을 사용하려면 NVIDIA 또는 Neuron DRA driver도 사용해야 합니다. 자세한 내용은 Manage NVIDIA GPUs on Amazon EKS와 Manage Neuron devices on Amazon EKS를 참고하세요.

다음 예제는 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 driver 문서를 참고하세요.

allocationMode를 사용해서 정렬된 GPU 또는 Neuron 가속기에 EFA 장치를 할당하는 방식을 단순화할 수 있어요. allocationMode 필드는 두 값을 지원합니다. ExactCount(기본값)는 count로 지정된 특정 수의 장치를 요청하고, All은 풀의 모든 일치 장치를 요청합니다. 예를 들어 p5.48xlarge 인스턴스에는 한 GPU와 같은 PCIe 루트를 공유하는 EFA 장치가 4개 있어요. EFA-GPU 장치 매핑과 정렬된 EFA 장치 수를 정확히 모르더라도 정렬된 GPU로 이 EFA 장치 그룹을 할당하려면 EFA 장치에 대해 allocationMode: All로 ResourceClaimTemplate을 구성할 수 있습니다.

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"

여러 Pod 간 EFA 장치 공유

EFA DRA driver는 ResourceClaim을 사용해서 여러 Pod 간 EFA 장치 공유를 지원합니다. 각 Pod마다 별도 클레임을 생성하는 ResourceClaimTemplate과 달리, ResourceClaim은 독립적으로 만들고 여러 Pod에서 참조하는 명명된 객체입니다. 같은 ResourceClaim을 참조하는 모든 Pod는 같은 할당된 EFA 장치에 대한 접근을 공유하고 해당 장치를 사용할 수 있는 같은 노드에 스케줄링돼요.

Pod 간 EFA 장치를 공유하려면 EFA 장치를 요청하는 ResourceClaim을 만든 다음, 각 Pod의 resourceClaims 필드에서 resourceClaimName으로 그 클레임을 이름으로 참조하세요. ResourceClaim은 이를 참조하는 Pod가 생성되기 전에 클러스터에 존재해야 합니다. 참조된 ResourceClaim이 존재하지 않으면 참조하는 Pod는 클레임이 생성될 때까지 pending 상태로 남습니다.

다음 예제는 4개의 EFA 장치를 요청하는 ResourceClaim과 해당 장치에 대한 접근을 공유하는 두 Pod를 만듭니다.

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

EFA 장치에 접근이 필요한 각 Pod에서 ResourceClaim을 이름으로 참조합니다. 각 Pod는 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

두 Pod 모두 같은 shared-efa ResourceClaim을 참조하고 해당 EFA 장치가 할당된 노드에 스케줄링됩니다. ResourceClaim의 수명 주기는 Pod와 독립적입니다. 이를 참조하는 모든 Pod가 제거되더라도 삭제할 때까지 유지돼요.

EFA Kubernetes device plugin 설치

EFA Kubernetes device plugin은 EFA 장치를 vpc.amazonaws.com/efa 확장 리소스로 광고합니다. 컨테이너 리소스 요청과 한도에서 EFA 장치를 요청해요. 학습 워크로드로 EFA를 설정하는 전체 연습은 Run machine learning training on Amazon EKS with Elastic Fabric Adapter를 참고하세요.

중요

NVIDIA GPU 또는 Neuron 장치와 EFA 인터페이스의 토폴로지 정렬 할당은 EKS 최적화 AL2023 가속 AMI를 사용할 때 자동으로 이루어집니다. 이 자동 정렬은 Bottlerocket EKS 최적화 AMI나 사용자 정의 AMI를 사용할 때는 발생하지 않아요. Bottlerocket 또는 사용자 정의 AMI에서 토폴로지 정렬 가속기·EFA 장치 할당이 필요하다면 EFA DRA driver와 해당 Neuron DRA driver를 사용하세요. Bottlerocket에서 NVIDIA DRA driver를 사용하려면 먼저 Bottlerocket NVIDIA 변형에 번들된 NVIDIA device plugin을 비활성화해야 하며, Bottlerocket 버전 1.63.0 이상이 필요합니다. 자세한 내용은 Topology-aware EFA and GPU/Neuron device allocation과 Install the NVIDIA DRA driver를 참고하세요.

중요

NVIDIA k8s-device-plugin v0.19.0부터 --mofed-enabled 플래그는 기본적으로 true이며, 이로 인해 NVIDIA device plugin이 GPU를 요청하는 컨테이너에 모든 /dev/infiniband/uverbs* 장치를 마운트합니다. 이는 /dev/infiniband에서 EFA 장치 할당을 관리해야 하는 컴포넌트인 EFA device plugin과 충돌합니다. EKS 관리형 노드 그룹이나 자체 관리 노드를 NVIDIA device plugin과 함께 사용한다면 MOFED를 명시적으로 비활성화해야 해요. 지침은 Install the NVIDIA Kubernetes device plugin을 참고하세요.

EKS Auto Mode는 기본적으로 MOFED를 활성화하지 않으며 이 문제의 영향을 받지 않습니다.

사전 조건

  • Amazon EKS 클러스터.
  • EFA 지원 Amazon EC2 인스턴스 유형의 노드. 지원되는 인스턴스 유형 목록은 Amazon EC2 User Guide의 Supported instance types를 참고하세요.
  • EFA용 호스트 수준 구성 요소가 설치된 노드. 자세한 내용은 Install the EFA software를 참고하세요. EKS 최적화 AL2023 AMI와 Bottlerocket AMI는 EFA 호스트 수준 구성 요소를 포함합니다.
  • 명령줄 환경에 Helm 설치. 자세한 내용은 Setup Helm 지침을 참고하세요.
  • 클러스터와 통신하도록 구성된 kubectl. 자세한 내용은 Install or update kubectl을 참고하세요.

절차

EKS Helm chart 저장소를 추가합니다.

helm repo add eks https://aws.github.io/eks-charts

로컬 Helm 저장소를 업데이트합니다.

helm repo update

EFA device plugin을 설치합니다.

helm install efa eks/aws-efa-k8s-device-plugin -n kube-system

EFA device plugin 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

노드에 할당 가능한 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

device plugin을 사용해서 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: ...

더 알아보기 (Learn more)

출처: 문서