EKS Auto Mode

Deep Dive Architecture

Junseok Oh

Sr. Solutions Architect

Amazon Web Services

EKS Auto Mode Deep Dive

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

Karpenter 기반 관리형 노드 자동 스케일링

Auto Mode란?

AWS 관리형 Karpenter로 노드 프로비저닝 자동화

핵심 특징

AWS가 Control Plane 내에서 Karpenter를 관리형으로 운영
NodePool/NodeClass로 노드 프로비저닝 제어
Managed Node Group 대비: 노드 관리 오버헤드 제거
빠른 스케일링: 40-90초 내 Pod 실행

기본 NodePool

general-purpose

범용 워크로드용, amd64/arm64, On-Demand + Spot 지원

system

시스템 컴포넌트 전용, CriticalAddonsOnly taint 적용

Karpenter를 직접 설치/관리할 필요 없이, EKS가 모든 것을 자동 처리합니다.

Auto Mode vs MNG vs Fargate

노드 관리 방식 비교

          Auto Mode
          
            특징Karpenter 기반, AWS 관리형, 인스턴스 다양화
스케일링자동 Consolidation, 40-90초 프로비저닝
비용Spot 인스턴스 자동 활용, 최적화된 bin-packing
적합 워크로드가변적 워크로드, 다양한 인스턴스 요구사항

        

특징	Karpenter 기반, AWS 관리형, 인스턴스 다양화
스케일링	자동 Consolidation, 40-90초 프로비저닝
비용	Spot 인스턴스 자동 활용, 최적화된 bin-packing
적합 워크로드	가변적 워크로드, 다양한 인스턴스 요구사항

Managed Node Group

특징	ASG 기반, Launch Template, 수동 설정
스케일링	Cluster Autoscaler 필요, 2-5분 소요
비용	인스턴스 타입 고정, 수동 Spot 설정
적합 워크로드	예측 가능한 워크로드, 특정 인스턴스 요구

Fargate

특징	서버리스, Pod 단위 격리, 노드 관리 없음
스케일링	Pod 단위 자동, 30-60초 소요
비용	vCPU/메모리 기반 과금, 유휴 비용 없음
적합 워크로드	배치 작업, 간헐적 워크로드, 보안 격리

내부 아키텍처

Karpenter가 Control Plane 내에서 동작하는 방식

NodePool 구조

기본 제공 NodePool 비교

특징

범용 워크로드용 기본 NodePool
amd64 및 arm64 아키텍처 지원
On-Demand + Spot 인스턴스 혼합
WhenEmptyOrUnderutilized Consolidation

YAMLapiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general-purpose
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: [amd64, arm64]
        - key: karpenter.sh/capacity-type
          operator: In
          values: [on-demand, spot]
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

특징

시스템 컴포넌트 전용 NodePool
amd64 아키텍처만 지원
On-Demand 인스턴스만 사용 (안정성)
CriticalAddonsOnly taint로 일반 워크로드 차단

YAMLapiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: system
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: [amd64]
        - key: karpenter.sh/capacity-type
          operator: In
          values: [on-demand]
      taints:
        - key: CriticalAddonsOnly
          effect: NoSchedule

NodeClass 설정

인터랙티브 NodeClass 빌더

설정 옵션

AMI: AL2023 AMI: Bottlerocket Subnet: Private Subnet: Public EBS: 50Gi gp3 EBS: 100Gi gp3 EBS: 200Gi gp3 IMDSv2 Required

생성된 NodeClass

YAMLapiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2023
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: my-cluster
        network-type: private
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 50Gi
        volumeType: gp3
  metadataOptions:
    httpTokens: required

커스텀 NodePool 패턴

워크로드 특성에 따른 NodePool 분리 전략

compute-optimized.yamlapiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: compute-optimized
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: [c]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["6"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: [on-demand]
  limits:
    cpu: 1000

Compute-optimized 특징

C 패밀리 (c7i, c7a) — vCPU 당 비용 최적
7세대 이상 최신 인스턴스만 사용
배치 처리, 인코딩, 고성능 API 서버에 적합
On-Demand로 안정적 운영

spot-mixed.yamlapiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-mixed
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: [m, c, r]
        - key: karpenter.k8s.aws/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 혼합으로 비용 60~70% 절감
다양한 카테고리 (m, c, r) 로 Spot 풀 확대
6세대 이상으로 Spot 가용성 극대화
Stateless 워크로드, 개발/스테이징 환경에 적합

Spot 인터럽트 대비: PDB 설정 + 다중 AZ 분산 필수

graviton.yamlapiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: graviton
spec:
  template:
    spec:
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: [arm64]
        - key: karpenter.k8s.aws/instance-category
          operator: In
          values: [m, c, r]
        - key: karpenter.k8s.aws/instance-generation
          operator: Gt
          values: ["6"]
  limits:
    cpu: 2000

Graviton 특징

ARM64 아키텍처 — 가성비 최대 40% 향상
m7g, c7g, r7g 시리즈 자동 선택
컨테이너 이미지 multi-arch 빌드 필요
대부분의 워크로드에서 x86 대비 성능 동등 이상

docker buildx build --platform linux/amd64,linux/arm64 으로 멀티 아키텍처 이미지 빌드

gpu-nodepool.yamlapiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  template:
    spec:
      requirements:
        - key: karpenter.k8s.aws/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 특징

g5/g6 (추론), p4d/p5 (학습) 자동 선택
On-Demand만 사용 (GPU Spot 가용성 제한)
Taint로 GPU 워크로드만 스케줄링
WhenEmpty — 비싼 GPU 노드 빠르게 회수

GPU 인스턴스는 비용이 높으므로 limits 설정이 중요합니다.

Pod Pending에서 Node Ready까지

프로비저닝 타임라인 시뮬레이션

Speed:

0.0s

인스턴스 선택 알고리즘

필터링 과정 시각화

Karpenter는 Pod 요구사항과 NodePool 제약을 기반으로 최적의 인스턴스를 자동 선택합니다.

Consolidation 동작 원리

노드 통합으로 비용 최적화

절감: $0.00/hr

Consolidation 정책 비교

WhenEmpty vs WhenEmptyOrUnderutilized

WhenEmpty

Pod가 0개인 노드만 제거
안전하지만 비효율적일 수 있음
GPU 워크로드에 적합

WhenEmptyOrUnderutilized
저사용률 노드도 통합
더 공격적인 비용 최적화
일반 워크로드에 권장

Drift 감지와 교체

NodePool/NodeClass 변경 시 자동 롤링 업데이트

NodePool/NodeClass 변경

→

Drift 감지

→

신규 노드 프로비저닝

→

Pod 이동

→

구 노드 종료

Drift 발생 조건

AMI Family 변경
인스턴스 타입 요구사항 변경
Subnet/SecurityGroup 변경
Block Device 설정 변경

안전한 교체 보장

PodDisruptionBudget 준수
Disruption Budget 적용
점진적 롤링 (한 번에 모든 노드 교체하지 않음)

Disruption Budget

안전한 노드 교체를 위한 제한 설정 — Drift 시뮬레이션

Nodes: 10

Budget: 10%

minAvailable: 0

1

Max 동시 교체

9

Min 유지

—

진행

YAMLspec:
  disruption:
    budgets:
      - nodes: "10%"

Healthy Drifted Draining New Node Replaced

스케일링 속도 최적화 팁

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

Bottlerocket AMI 사용
부팅 시간 10-20초 단축
# NodeClass spec: amiSelectorTerms: - alias: bottlerocket@latest
작은 EBS 볼륨
볼륨 초기화 5-10초 단축
# NodeClass spec: blockDeviceMappings: - deviceName: /dev/xvda ebs: volumeSize: 20Gi volumeType: gp3
다양한 인스턴스 타입 허용
가용성 향상, 빠른 프로비저닝
# NodePool spec: template: spec: requirements: - key: karpenter.k8s.aws/instance-family operator: In values: [m7i, m7g, c7i, c7g, r7i] - key: karpenter.k8s.aws/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

Block 1 요약 & 퀴즈

학습 내용 확인

1. EKS Auto Mode의 기반 기술은?

2. Consolidation 정책 중 저사용률 노드도 통합하는 것은?

3. Auto Mode에서 Pod Pending에서 Node Ready까지 일반적 소요 시간은?

Thank You

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

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