EKS Auto Mode

Deep Dive Architecture

Junseok Oh

Sr. Solutions Architect

Amazon Web Services

EKS Auto Mode Deep Dive

Block 1: 내부 아키텍처 이해 (35분)

Karpenter 기반 관리형 노드 EKS 1.37 · 직접 설치 Karpenter v1.15.0 2026-10-15 검토, 직접 설치 시 1.37은 Karpenter 1.15.x 필요 (Auto Mode는 AWS 관리) · 공식 출처

노드는 자동으로, 앱 정책은 우리가

Karpenter의 역할과 Auto Mode의 관리 범위

Karpenter의 역할

배치되지 못한 Pod에 맞는
노드를 골라 추가합니다.

조건이 맞으면 노드를 정리해
불필요한 비용을 줄입니다.

Auto Mode에서 AWS가 할 일

Karpenter 기반 노드 관리와
OS·주요 인프라 구성 요소를 관리합니다.

Controller 설치·패치 부담을 줄입니다.

우리 팀이 할 일

앱에 필요한 CPU·메모리,
배치 조건과 중단 허용 범위를 정합니다.

앱의 가용성은 함께 설계해야 합니다.

Pod = 앱 실행 단위 · Node = Pod가 실행되는 서버.
Auto Mode를 이해할 때는 “무엇을 자동화하나”와 “누가 관리하나”를 함께 보세요.
최신 버전은 무엇을 의미하나요?

EKS: 1.37 · 직접 설치한 Karpenter: v1.15.0 (2026-10-15 확인).

Auto Mode에 별도 Helm 버전을 지정하지 않습니다. 직접 설치한 Karpenter는 공식 호환성 표 기준 Kubernetes 1.37에 1.15.x가 필요합니다. 공식 출처·변경 사항

어디까지 직접 운영할까요?

Auto Mode와 직접 설치한 Karpenter부터 비교

Auto Mode

특징Karpenter 기반, AWS 관리형, 인스턴스 다양화
스케일링Balanced 기본 정책 (EKS 1.37 신규 풀), 수요 기반 프로비저닝
비용EC2 + Auto Mode 관리 비용 (2026-07부터 GPU 계열 인하), 커스텀 풀에서 Spot 활용
2026 추가 기능NodeClass advancedCompute, EFA 인터페이스, ARC zonal shift 대응, EC2 상태 검사 실패 노드 자동 교체
적합 워크로드가변적 워크로드, 다양한 인스턴스 요구사항

설정 자유도와 운영 책임을 함께 가져갑니다

팀이 관리Controller · CRD · IAM · AMI 선택/업데이트
노드 설정NodePool + EC2NodeClass
잘 맞는 경우AMI와 노드 구성을 직접 제어해야 할 때
업그레이드v1.15.0 · Controller와 CRD를 함께 확인 (1.37은 1.15.x 필요)

Managed Node Group

특징ASG 기반, Launch Template, 수동 설정
스케일링Cluster Autoscaler 등으로 노드 그룹 용량 조절
비용노드 그룹 단위로 인스턴스 타입·Spot 구성
적합 워크로드예측 가능한 워크로드, 특정 인스턴스 요구

Fargate

특징서버리스, Pod 단위 격리, 노드 관리 없음
스케일링Pod 단위 용량 제공 · 실제 시작 시간은 환경에 따라 다름
비용vCPU/메모리 기반 과금, 유휴 비용 없음
적합 워크로드배치 작업, 간헐적 워크로드, 보안 격리

Pod가 기다리면 누가 움직일까요?

배치 불가(FailedScheduling) 예시 → 용량 계획 → 노드 준비 → Pod 배치

단계 버튼 또는 ↑ ↓
핵심: Karpenter는 노드를 준비하고, Kubernetes Scheduler는 Pod를 배치합니다.

NodePool: 어떤 노드를 허용할까요?

먼저 기본 풀의 역할을 구분하고, 필요한 경우 설정을 펼쳐 보세요

일반 앱을 실행할 자리

  • 범용 워크로드용 기본 NodePool
  • amd64 아키텍처 지원
  • On-Demand 인스턴스만 사용
  • EKS 1.37에서는 Balanced 정책

Spot을 쓰려면 별도 커스텀 풀을 만듭니다.

NodePool YAML 발췌 보기

읽기용 발췌입니다. AWS가 관리하는 기본 풀은 직접 수정하지 않습니다.

YAMLapiVersion: karpenter.sh/v1 kind: NodePool metadata: name: general-purpose spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: kubernetes.io/arch operator: In values: [amd64] - key: karpenter.sh/capacity-type operator: In values: [on-demand] disruption: consolidationPolicy: Balanced

시스템 Pod를 위한 자리

  • 시스템 컴포넌트 전용 NodePool
  • amd64 및 arm64 아키텍처 지원
  • On-Demand 인스턴스만 사용
  • CriticalAddonsOnly taint 사용

taint를 허용하는 toleration이 있어야 배치 후보가 됩니다.

NodePool YAML 발췌 보기

기본 풀은 직접 수정하지 않습니다. 두 기본 풀 모두 EKS 1.37에서는 Balanced를 사용합니다.

YAMLapiVersion: karpenter.sh/v1 kind: NodePool metadata: name: system spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: default requirements: - key: kubernetes.io/arch operator: In values: [amd64, arm64] - key: karpenter.sh/capacity-type operator: In values: [on-demand] taints: - key: CriticalAddonsOnly effect: NoSchedule
NodePool = 허용할 노드의 조건.
Spot·별도 인스턴스 조건은 커스텀 풀에 설정합니다. 기본 풀은 활성화·비활성화만 가능합니다.

NodeClass: AWS에서 어떻게 만들까요?

노드를 만들 때 필요한 AWS 설정 세 가지

어디에 연결하나?

Subnet · Security Group

네트워크 위치와 허용할 통신을 정합니다.

어떤 권한을 쓰나?

노드 IAM 역할

노드가 AWS API와 클러스터에 접근할 권한을 준비합니다.

얼마나 저장하나?

로컬 스토리지

컨테이너 이미지와 로그 등에 쓸 디스크 크기를 정합니다.

Auto Mode는 NodeClass · 직접 설치한 Karpenter는 EC2NodeClass.
목적은 비슷하지만 API와 설정 필드가 다릅니다. Auto Mode의 OS·AMI는 AWS가 관리합니다.
옵션을 바꾸며 전체 YAML 확인하기

설정 옵션

AMI·IMDS 보안은 AWS 관리.
노드 역할: EC2 Access Entry + AmazonEKSAutoNodePolicy

변경 결과를 확인하세요

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: workload spec: role: MyAutoModeNodeRole subnetSelectorTerms: - tags: karpenter.sh/discovery: my-cluster network-type: private securityGroupSelectorTerms: - tags: karpenter.sh/discovery: my-cluster ephemeralStorage: size: 80Gi

예제의 network-type은 직접 붙인 subnet 태그입니다. Private subnet에는 필요한 NAT 또는 VPC endpoint 연결도 준비해야 합니다.

2026-10 추가: advancedCompute로 노드 설정 조정하기
kubeletmaxPods, podPidsLimit, eviction, 컨테이너 로그 회전, allowedUnsafeSysctls
kernel.sysctl지원 목록의 항목만 허용 (예: net.core.somaxconn, vm.max_map_count, ARP cache)
hugepages2Mi/1Gi 고정 예약 또는 THP 정책. Pod는 hugepages-2Mi 등을 요청

변경하면 기존 노드는 Drift로 교체되고 새 노드부터 반영됩니다. static hugepages와 EFA는 같은 NodeClass에 함께 쓸 수 없습니다.

# 필요한 항목만 지정 spec: advancedCompute: kubelet: maxPods: 60 # 1-110 kernel: sysctl: net.core.somaxconn: 4096 hugepages: pages: - size: "2Mi" count: 512

공식 문서: NodeClass kubelet, sysctl, hugepages

요구가 다를 때 커스텀 풀을 만듭니다

먼저 워크로드 목적을 고르고, requirements에서 바뀐 조건을 확인

앞에서 만든 workload NodeClass를 사용합니다. 네트워크·IAM 준비 후 적용하는 예제입니다.

Compute YAML 보기
compute-optimized.yamlapiVersion: karpenter.sh/v1 kind: NodePool metadata: name: compute-optimized spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: workload requirements: - key: eks.amazonaws.com/instance-category operator: In values: [c] - key: eks.amazonaws.com/instance-generation operator: Gt values: ["6"] - key: karpenter.sh/capacity-type operator: In values: [on-demand] limits: cpu: 1000

Compute-optimized 특징

  • CPU 중심 작업에 C 계열을 허용하는 예시
  • 7세대 이상 허용 — 성능·용량은 별도 확인
  • 배치 처리·인코딩 등에서 먼저 측정
  • 이 예제는 On-Demand 선택
Spot YAML 보기
spot-mixed.yamlapiVersion: karpenter.sh/v1 kind: NodePool metadata: name: spot-mixed spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: workload requirements: - key: eks.amazonaws.com/instance-category operator: In values: [m, c, r] - key: eks.amazonaws.com/instance-generation operator: Gt values: ["5"] - key: karpenter.sh/capacity-type operator: In values: [spot, on-demand] disruption: consolidationPolicy: WhenEmptyOrUnderutilized

Spot Mixed 특징

  • Spot 우선, 가용 용량에 따라 On-Demand 사용
  • 다양한 카테고리 (m, c, r) 로 Spot 풀 확대
  • 용량 유형을 허용해도 혼합 비율은 보장되지 않음
  • 실제 절감률과 재시작 영향을 함께 측정
중단을 감수할 수 있는 작업부터 시작하고, 여유 용량·분산 배치·재시작 시간을 확인하세요.
Graviton YAML 보기
graviton.yamlapiVersion: karpenter.sh/v1 kind: NodePool metadata: name: graviton spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: workload requirements: - key: kubernetes.io/arch operator: In values: [arm64] - key: eks.amazonaws.com/instance-category operator: In values: [m, c, r] - key: eks.amazonaws.com/instance-generation operator: Gt values: ["6"] limits: cpu: 2000

Graviton 특징

  • arm64 호환 앱을 위한 Graviton 예시
  • 허용한 M/C/R 계열 중 조건에 맞는 노드 선택
  • arm64 이미지 또는 multi-arch 이미지 필요
  • 라이브러리 호환성과 앱의 비용·성능을 측정
docker buildx build --platform linux/amd64,linux/arm64 으로 멀티 아키텍처 이미지 빌드
GPU YAML 보기
gpu-nodepool.yamlapiVersion: karpenter.sh/v1 kind: NodePool metadata: name: gpu spec: template: spec: nodeClassRef: group: eks.amazonaws.com kind: NodeClass name: workload requirements: - key: eks.amazonaws.com/instance-category operator: In values: [g, p] - key: karpenter.sh/capacity-type operator: In values: [on-demand] taints: - key: nvidia.com/gpu effect: NoSchedule limits: nvidia.com/gpu: 100 disruption: consolidationPolicy: WhenEmpty

GPU NodePool 특징

  • G/P 계열 중 리소스·드라이버 요구에 맞게 선택
  • On-Demand만 사용 (이 예제의 선택; Spot은 별도 검토 가능)
  • Taint를 허용하는 toleration과 GPU 요청 필요
  • WhenEmpty — 빈 노드의 정리를 검토
GPU 인스턴스는 비용이 높으므로 limits 설정이 중요합니다.

Pod Pending에서 Node Ready까지

프로비저닝 타임라인 시뮬레이션 · 시간은 설명용 예시, SLA 아님

0.0s

조건에 맞는 후보부터 좁힙니다

12개 이름으로 보는 필터 연습 · 실제 가격·용량 계산은 생략

정답은 항상 Graviton 한 종류가 아닙니다.
이 예시는 amd64·arm64 모두 호환되는 앱을 가정합니다. 실제 선택은 Pod 요청량·배치 조건·가용 용량·가격도 함께 반영합니다.

Pod를 옮길 자리가 있어야 줄입니다

Consolidation = Pod를 재배치하고 불필요한 노드 정리 · 모두 한 노드에 들어가는 예시

절감: $0.00/hr

조금 싸져도 Pod를 옮길까요?

상황을 고르면 세 가지 Consolidation 정책을 비교할 수 있습니다

비었을 때만

WhenEmpty

실행 중인 일반 워크로드가 없는 노드를 정리합니다.

절감 기회가 있으면

WhenEmptyOrUnderutilized

Pod를 옮길 수 있고 더 저렴하게 운영할 수 있으면 통합을 검토합니다.

절감과 중단을 함께

Balanced

비용 절감과 Pod 중단 비용을 함께 평가합니다.

EKS 1.37의 새 Auto Mode NodePool 기본값은 Balanced.
직접 설치한 Karpenter v1.15도 기본값이 WhenEmptyOrUnderutilized이므로 정책을 명시적으로 선택합니다.

교육용 정성 비교입니다. 실제 결정은 배치 가능성, PDB, 교체 예산 등에도 영향을 받습니다.

Drift 감지와 교체

기존 노드가 원하는 설정과 맞지 않으면 교체를 검토합니다

NodePool/NodeClass 변경
→
Drift 감지
→
신규 노드 프로비저닝
→
Pod 이동
→
구 노드 종료
Drift 발생 조건
  • AWS 관리 AMI 업데이트 또는 NodeClass 변경
  • 기존 노드와 맞지 않는 인스턴스 요구사항
  • Subnet/SecurityGroup 변경
  • ephemeralStorage 설정 변경

모든 변경이 Drift는 아닙니다. limits·weight·disruption 변경은 Drift를 유발하지 않으며, 허용 범위를 넓혀도 기존 노드가 계속 맞을 수 있습니다.

교체 중단 제어
  • PodDisruptionBudget 준수
  • Disruption Budget 적용
  • 점진적 롤링 · PDB가 만료/Spot 회수 기한을 연장하지 않음

한 번에 몇 대까지 바꿀까요?

NodePool 예산은 노드 수 · PDB는 앱의 Pod 중단 제어

Drift 교체 예시: 10대 × 10% = 한 번에 최대 1대. 비율은 올림, 여러 예산은 최솟값을 적용합니다. 삭제 중·NotReady 노드는 0개로 가정합니다.

1
Max 동시 교체
9
Min 유지
—
진행
YAMLspec: disruption: budgets: - nodes: "10%"
Healthy Drifted Draining New Node Replaced

스케일링 속도 최적화 팁

프로비저닝 시간 단축을 위한 Best Practices

  • 관리형 AMI 교체 확인
    AWS가 AMI 선택·패치 관리
    # Auto Mode: AMI 선택 필드 없음 # AWS 관리 AMI, SSH/SSM 직접 접근 불가 kubectl get nodeclaims
  • ephemeralStorage 크기 설정
    이미지·로그 용량에 맞게 구성
    # Auto Mode NodeClass 설정 발췌 spec: ephemeralStorage: size: 80Gi
  • 다양한 인스턴스 타입 허용
    가용성 향상, 빠른 프로비저닝
    # NodePool spec: template: spec: requirements: - key: eks.amazonaws.com/instance-family operator: In values: [m7i, m7g, c7i, c7g, r7i] - key: eks.amazonaws.com/instance-size operator: In values: [large, xlarge, 2xlarge]
  • Pod Topology Spread 설정
    워크로드 분산, 안정성 향상
    # Pod spec topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: my-app
  • PriorityClass로 중요 워크로드 우선
    Preemption 활용
    apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: critical-workload value: 1000000 globalDefault: false
  • Disruption Budget으로 안전한 교체
    서비스 중단 최소화
    # NodePool spec: disruption: budgets: - nodes: "20%" schedule: "0 9 * * *" duration: 8h

세 가지 상황으로 확인해 봅시다

하나씩 답을 고르고, 해설에서 이유를 확인하세요

Auto Mode에서 팀이 직접 정해야 하는 것은?
Spot을 허용하는 조건과 subnet 설정은 어디에 둘까요?
절감은 작은데 Pod 재시작 영향은 큽니다. 무엇을 검토할까요?

Thank You

Block 1 — EKS Auto Mode 내부 아키텍처 완료

← 목차로 돌아가기 다음: Block 2 →