EKS Auto Mode로 Capacity Reservations에 워크로드 배포 제어하기
EKS Auto Mode로 Capacity Reservations에 워크로드 배포 제어하기
Capacity Reservations에 워크로드 배포를 제어할 수 있어요. EKS Auto Mode는 EC2 On-Demand Capacity Reservations(ODCR), EC2 Capacity Blocks for ML, Interruptible Capacity Reservations(IODCR)을 지원합니다.
Tip: 기본적으로 EKS Auto Mode는 open-matching을 통해 열린(open) ODCR에 시작할 수 있지만 우선시하지는 않습니다. open-matching으로 시작된 인스턴스는
karpenter.sh/capacity-type: on-demand로 라벨이 지정되며reserved가 아닙니다. ODCR 사용을 우선시하고 인스턴스에karpenter.sh/capacity-type: reserved라벨을 지정하려면 NodeClass 정의에서capacityReservationSelectorTerms를 구성하세요. Capacity Blocks for ML은 항상capacityReservationSelectorTerms가 필요하며 자동으로 사용되지 않습니다.
출처: 문서
본문
EC2 On-Demand Capacity Reservations(ODCR)
EC2 On-Demand Capacity Reservations(ODCR)을 사용하면 특정 Availability Zone에서 임의 기간 동안 Amazon EC2 인스턴스의 컴퓨트 용량을 예약할 수 있어요. EKS Auto Mode를 사용할 때 사전 구매한 용량의 활용을 최대화하거나 크리티컬 워크로드가 보장된 리소스에 접근하도록 Kubernetes 워크로드를 이러한 예약 인스턴스에 배포할지 제어하고 싶을 수 있습니다.
기본적으로 EKS Auto Mode는 열린 ODCR에 자동으로 시작합니다. 하지만 NodeClass에서 capacityReservationSelectorTerms를 구성하면 워크로드가 사용하는 ODCR을 명시적으로 제어할 수 있어요. 구성된 ODCR을 사용해 프로비저닝된 노드는 karpenter.sh/capacity-type: reserved 라벨을 가지며 on-demand와 spot보다 우선시됩니다. 이 기능이 활성화되면 EKS Auto Mode는 더 이상 열린 ODCR을 자동으로 사용하지 않으며, NodeClass가 명시적으로 선택해야 합니다. 이를 통해 클러스터 전체에서 용량 예약 사용을 정밀하게 제어할 수 있어요.
Warning: 클러스터의 NodeClass에서
capacityReservationSelectorTerms를 구성하면 EKS Auto Mode는 클러스터의 어떤 NodeClass에 대해서도 더 이상 열린 ODCR을 자동으로 사용하지 않습니다.
예시 NodeClass:
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
이 예시 NodeClass는 ODCR 선택의 두 가지 접근 방식을 보여 줍니다. 첫 번째 방법은 ID(cr-56fac701cc1951b03)로 특정 ODCR을 직접 참조합니다. 두 번째 방법은 태그 기반 선택으로 Name: "targeted-odcr" 태그가 있는 ODCR을 대상으로 합니다. 선택적으로 예약을 소유한 AWS 계정으로 필터링할 수도 있는데, 이는 교차 계정 시나리오나 공유 용량 예약 작업 시 특히 유용합니다.
Capacity Reservations용 스케줄링 라벨
NodeClass에서 capacityReservationSelectorTerms를 구성하면 용량 예약에서 프로비저닝된 노드에 추가 스케줄링 라벨이 지정됩니다. 이 라벨을 NodePool 요구사항이나 Pod 스케줄링 제약(예: node affinity)으로 사용해 워크로드 배치를 제어할 수 있어요.
| 라벨 | 예시 | 설명 |
|---|---|---|
eks.amazonaws.com/capacity-reservation-id |
cr-56fac701cc1951b03 |
용량 예약의 ID |
eks.amazonaws.com/capacity-reservation-type |
default 또는 capacity-block |
용량 예약의 유형 |
eks.amazonaws.com/capacity-reservation-interruptible |
true 또는 false |
용량 예약이 인터럽트 가능한지 여부 |
이 라벨들은 karpenter.sh/capacity-type: reserved 노드에만 존재합니다.
Interruptible Capacity Reservations(IODCR)
Interruptible Capacity Reservations을 사용하면 조직 내 다른 워크로드와 사용하지 않는 On-Demand Capacity Reservation 용량을 공유할 수 있어요. 사용하지 않는 용량을 인터럽트 가능한 ODCR로 재사용함으로써 배치 처리·데이터 분석 같은 유연하고 내결함성이 있는 운영에 적합한 워크로드가 일시적으로 사용 가능한 용량을 활용할 수 있습니다. 예약 소유자는 언제든지 용량을 회수할 수 있으며, 인터럽트 가능한 ODCR의 소비자는 노드가 종료되기 전에 정상 종료 또는 체크포인트가 가능하도록 종료 전에 인터럽트 알림을 받아요.
표준 ODCR과 동일하게 ID 또는 태그로 capacityReservationSelectorTerms를 사용해 인터럽트 가능한 용량 예약을 선택합니다. 워크로드가 인터럽트 가능한 예약 용량에 스케줄링될지 비인터럽트 예약 용량에 스케줄링될지 제어하려면 eks.amazonaws.com/capacity-reservation-interruptible 스케줄링 라벨을 사용하세요.
용량이 회수되면 실행 중인 인스턴스는 EventBridge 이벤트로 2분 인터럽트 경고를 받습니다. 알림 기간이 지나면 회수된 용량의 실행 중인 인스턴스는 종료 중 상태가 되고 종료됩니다. EKS Auto Mode는 2분 인터럽트 경고를 받으면 인터럽트 가능한 용량 예약에서 시작된 노드 드레인을 자동으로 시작하여, 노드가 회수되기 전에 워크로드가 정상적으로 종료될 수 있게 합니다.
EC2 Capacity Blocks for ML
Capacity Blocks for ML은 향후 날짜에 GPU 기반 가속 컴퓨팅 인스턴스를 예약해 짧은 기간의 머신 러닝(ML) 워크로드를 지원합니다. Capacity Block 안에서 실행되는 인스턴스는 저지연, 페타비트 규모, 비차단 네트워킹을 위해 Amazon EC2 UltraClusters 안에 자동으로 근접 배치됩니다.
지원 플랫폼과 인스턴스 유형에 대한 자세한 내용은 EC2 User Guide의 Capacity Blocks for ML을 참고하세요.
(앞서 설명한 ODCR과 유사하게) Capacity Block for ML을 사용하는 EKS Auto Mode NodeClass를 만들 수 있습니다. 다음 샘플 정의는 세 가지 리소스를 만듭니다.
- Capacity Block 예약을 참조하는 NodeClass
- NodeClass를 사용하고 taint를 적용하는 NodePool
- taint를 허용하고 GPU 리소스를 요청하는 Pod 사양
예시 NodeClass — 이 NodeClass는 예약 ID로 특정 Capacity Block for ML을 참조합니다. 이 ID는 EC2 콘솔에서 얻을 수 있어요.
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
자세한 내용은 Create a Node Class for Amazon EKS를 참고하세요.
예시 NodePool — 이 NodePool은 gpu NodeClass를 참조하고 중요한 구성을 지정합니다.
karpenter.sh/capacity-type: reserved를 설정해 예약 용량만 사용합니다.- ML 워크로드에 적합한 특정 GPU 인스턴스 패밀리를 요청합니다.
- GPU 워크로드만 이 노드에 스케줄링되도록
nvidia.com/gputaint를 적용합니다.
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
자세한 내용은 Create a Node Pool for EKS Auto Mode를 참고하세요.
예시 Pod — 이 예시 Pod는 Capacity Block 노드에서 워크로드를 실행하도록 구성하는 방법을 보여 줍니다.
- 특정 GPU 유형(이 경우 H200 GPU)을 대상으로 하는 nodeSelector를 사용합니다.
- NodePool이 적용한
nvidia.com/gputaint에 대한 toleration을 포함합니다. nvidia.com/gpu리소스 유형으로 GPU 리소스를 명시적으로 요청합니다.
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
자세한 내용은 Kubernetes 문서의 Pods를 참고하세요.
관련 리소스
- Amazon EC2 User Guide의 Capacity Blocks for ML
- Amazon EC2 User Guide의 Find and purchase Capacity Blocks
- Amazon EC2 User Guide의 Interruptible Capacity Reservations
- Manage compute resources for AI/ML workloads on Amazon EKS
- EKS Best Practices Guide의 GPU Resource Optimization and Cost Management