5부: 데모 영상

같은 조건, 두 클러스터: 스케일 아웃, Consolidation, Drift, Spot 중단

데모 환경: 같은 VPC, 같은 NodePool 조건

akd-auto: EKS Auto Mode
  • 노드 OS: Bottlerocket (EKS Auto, Standard) 2026.10.9
  • NodeClass demo (eks.amazonaws.com/v1)
  • 정책 미지정 시 라이브 값: Balanced, expireAfter 336h
akd-karp: 직접 설치 Karpenter 1.15.0
  • 노드 OS: Amazon Linux 2023 (AMI v20261003으로 시작)
  • EC2NodeClass default + interruption queue (SQS)
  • 정책 미지정 시 라이브 값: WhenEmptyOrUnderutilized, expireAfter 720h
공통 조건: EKS 1.37, ap-northeast-2, 데모 VPC의 private 서브넷 2개(2a, 2b). NodePool demo: on-demand, c/m/r 계열, generation 5 초과, amd64, consolidateAfter 30s, budget nodes: "1". 워크로드: pause 컨테이너, replica당 1 vCPU / 1.5Gi
노드에 공인 IP 없음. API endpoint는 작업 PC의 출구 IP 하나만 허용했습니다.

V1: 같은 Pending Pod 10개

실제 터미널 녹화(2026-10-20)와 실측 결과 재구성, 무음

V1 결과: 고른 인스턴스는 같고, 준비 시간은 달랐다

클러스터선택한 노드NodeClaim 생성 (UTC)노드 ReadyPod 10개 Ready
akd-auto (Auto Mode)c7i-flex.4xlarge 1대13:54:15+15초+28초
akd-karp (Karpenter 1.15.0)c7i-flex.4xlarge 1대13:54:15+40초+47초
결정 로직은 같다
같은 requirements와 같은 Pod 요청에 같은 인스턴스 유형, 같은 대수를 골랐습니다. Auto Mode 안에서도 Karpenter가 판단합니다.
시간 차이는 1회 측정
노드 OS(Bottlerocket과 AL2023)와 부팅 구성이 다릅니다. 직접 운영 시 AMI와 userData를 줄이는 만큼 달라질 수 있습니다.

V2: 정책을 비워 두면 무엇이 들어갈까

실제 터미널 녹화(2026-10-20)와 실측 결과 재구성, 무음

V2 결과: 같은 교체, Balanced는 점수로 승인했다

두 클러스터 모두 같은 순서
  1. DisruptionLaunching: 대체 NodeClaim(c7i-flex.2xlarge) 먼저 생성
  2. 새 노드 Ready 확인
  3. DisruptionTerminating: 기존 c7i-flex.4xlarge
  4. Evicted: Pod 4개가 새 노드로 이동
Auto Mode 이벤트 (ConsolidationApproved)
score 0.50 >= threshold 0.50
(k: 2, savings 50.0%, disruption 100.0%)
절감 비율을 disruption 비율로 나눈 점수가 임계값 이상일 때만 실행합니다. 노드 한 대뿐이라 disruption 100%였고, 절감 50%로 겨우 통과했습니다.
시점은 비교하지 않는다
녹화 회차는 Auto Mode +67초, Karpenter +75초에 첫 이동. 앞선 회차는 Karpenter 약 1분, Auto Mode 약 5분 30초 뒤였습니다. 정책의 속도 차이로 해석하지 않습니다.

V3: NodeClass를 바꾸면 노드는 한 대씩

실제 터미널 녹화(2026-10-20)와 실측 결과 재구성, 무음

V3 결과: 새 노드를 먼저, 한 번에 한 대

클러스터바꾼 값Launch, Terminate, Launch, Terminate (UTC)완료
akd-autoadvancedCompute.kubelet.maxPods: 6414:20:12, 14:20:30, 14:20:45, 14:21:00+98초
akd-karpal2023@v20261003 → al2023@v2026101214:20:10, 14:20:46, 14:20:57, 14:21:27+127초
maxPods 64, 실제는 56
새 Auto Mode 노드의 capacity.pods는 56이었습니다. 실제값은 설정값, 인스턴스 IP 수, 110 중 가장 작은 값입니다.
같은 EC2NodeClass는 함께 교체
AMI를 바꾸자 같은 EC2NodeClass를 쓰는 spot NodePool 노드도 Drift로 교체됐습니다. 영향 범위는 NodeClass 단위로 봅니다.

V4: Spot 중단 경고를 받으면

실제 터미널 녹화(2026-10-20)와 실측 결과 재구성, akd-karp만, 무음

V4 결과: Karpenter는 2분을 기다리지 않는다

14:23:15 UTCFIS 실험 시작 (Spot 인스턴스 1대, 2분 전 알림) 14:23:29 UTCSpotInterrupted: Pod 3개 Evicted, 대체 NodeClaim 지명 14:23:35 UTCKarpenter가 기존 인스턴스 종료 시작 14:24:00 UTC대체 노드(c7i-flex.xlarge spot) Ready, Pod 다시 Running
약 30초 동안 Running 0개
replica 3개가 모두 중단된 노드 한 대에 있었습니다. 대체 노드가 Ready가 될 때까지 서비스가 비었습니다.
대책: 분산과 여유
topology spread로 replica를 여러 노드와 zone에 나누고, 여러 인스턴스 유형을 허용해 대체 용량을 넓힙니다. PDB는 중단 drain에도 적용되지만 2분 뒤 회수는 막지 못합니다(이번 시험에는 PDB 없음).

6부: 오늘 가져갈 다섯 가지

1. 판단은 같은 Karpenter
Auto Mode도 같은 조건에 같은 노드를 골랐습니다. 차이는 누가 운영하느냐입니다.
2. 1.37 기본값을 명시
비워 두면 Auto Mode는 Balanced, Karpenter는 WhenEmptyOrUnderutilized입니다.
3. 버전 순서
직접 운영은 Karpenter 1.15.x와 CRD를 먼저, 그다음 Kubernetes 1.37입니다.
4. 교체는 budget으로
AMI는 버전을 고정하고, budget과 PDB로 교체 속도를 정합니다.
5. 배치가 가용성
Spot 중단에 견디는 힘은 replica 분산에서 나옵니다.

참고 자료와 Q&A

다음 단계
관측성과 리소스 최적화까지
EKS Auto Mode & Karpenter 운영: 노드 라이프사이클 모니터링, Grafana 상관분석, VPA와 KEDA
Auto Mode 운영 가이드
kubernetes-docs: EKS Auto Mode 운영 가이드: 시작하기, NodePool, 스케일링, Spot, 운영, 비용, 수명, 워크로드, 마이그레이션 9개 장
데모 스크립트
오늘 영상의 클러스터 구성, NodePool, 녹화 driver, 정리 스크립트는 요청 시 공유합니다.
Q&A
버전과 기본값은 2026-10-20 기준입니다. 적용 전에 최신 문서를 확인하세요.
공식 문서

Thank You

EKS Auto Mode와 Karpenter, 감사합니다

수고하셨습니다!

← 목차로 돌아가기