4부: Auto Mode 심화와 운영

켜기, 노드 설정, 용량, 진단, 비용, 마이그레이션, 그리고 무엇을 고를까

Auto Mode 켜기: IAM과 세 스위치

역할	필요한 것
클러스터 역할	신뢰: `sts:AssumeRole` + `sts:TagSession` 정책 (`AmazonEKS` 접두사): `ClusterPolicy`, `ComputePolicy`, `BlockStoragePolicyV2`, `LoadBalancingPolicy`, `NetworkingPolicy`
노드 역할	`AmazonEKSWorkerNodeMinimalPolicy`, `AmazonEC2ContainerRegistryPullOnly`
워크로드	Pod Identity로 따로 부여. OIDC provider 없이 활성화 가능

되돌릴 수 없는 것

CONFIG_MAP에서 API_AND_CONFIG_MAP 전환은 단방향. 기존 클러스터의 클러스터 역할 ARN은 교체 불가

# 기존 클러스터: 세 기능을 한 요청에서 함께
aws eks update-cluster-config --name $CLUSTER \
  --compute-config '{"enabled":true,
     "nodePools":["general-purpose","system"],
     "nodeRoleArn":"'$NODE_ROLE_ARN'"}' \
  --kubernetes-network-config \
     '{"elasticLoadBalancing":{"enabled":true}}' \
  --storage-config '{"blockStorage":{"enabled":true}}'
# eksctl: 새 클러스터 create cluster --enable-auto-mode
#         기존 클러스터 update auto-mode-config -f cluster.yaml
kubectl wait nodepool/general-purpose nodepool/system \
  --for=condition=Ready --timeout=300s

켠 직후 노드는 0대일 수 있음

Pending Pod가 생겨야 노드가 뜹니다. default NodeClass는 클러스터 subnet을 물려받으니 private subnet으로 클러스터를 만듭니다.

Built-in 풀과 default NodeClass

NodePool	아키텍처	용량, 인스턴스	누가 올라가나
`general-purpose`	`amd64`	On-Demand, C/M/R, 5세대 이상	일반 워크로드
`system`	`amd64`, `arm64`	On-Demand, C/M/R, 5세대 이상	`CriticalAddonsOnly` taint를 tolerate하는 Pod

수정하지 말고 추가

built-in 풀은 AWS 관리 객체입니다. Spot, Graviton 범용, GPU는 커스텀 NodePool로 만듭니다. 1.37에서 built-in 풀은 Balanced입니다.

default NodeClass 조건

built-in 풀이 하나 이상 켜져 있어야 생깁니다. 둘 다 끄면 NodeClass를 직접 만들고 참조를 바꿉니다.

목록에서 빼면 노드 종료

computeConfig.nodePools에서 이름을 지우면 그 풀의 노드가 drain, 종료됩니다. 새 Pod만 막는 설정이 아닙니다.

추측 말고 조회: kubectl get nodepool general-purpose system -o yaml, kubectl get nodeclass default -o yaml로 실제 disruption과 taint 값을 확인합니다.

커스텀 NodeClass: 필드 지도

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
  role: AmazonEKSAutoNodeRole  # 또는 instanceProfile
  subnetSelectorTerms:
  - tags: {kubernetes.io/role/internal-elb: "1"}
  securityGroupSelectorTerms:
  - tags: {Type: worker-node}
  ephemeralStorage:
    size: 100Gi
    iops: 3000
    throughput: 125
  advancedNetworking:
    associatePublicIPAddress: false
  advancedCompute:
    kernel:
      sysctl: {vm.max_map_count: 262144}
  tags: {Environment: production}

role과 instanceProfile은 하나만

AmazonEKSComputePolicy가 eks* 이름의 instance profile에만 권한을 주므로 이름을 eks로 시작합니다. 새 역할에는 access entry가 필요합니다.

tags는 클러스터 역할 권한 필요

커스텀 태그 키로 리소스를 만들 권한이 없으면 launch가 실패합니다. 데모에서 CreateLaunchTemplate 권한 오류로 확인했습니다.

sysctl 변경은 Drift

부팅 시 적용되므로 기존 노드는 교체됩니다. 실행 중인 노드에 바로 적용되지 않습니다.

필드	하는 일	주의
`ephemeralStorage.kmsKeyID`	노드 root, data EBS를 고객 관리 키로 암호화	같은 리전 키. NVMe instance store와 앱 PVC에는 적용 안 됨
`certificateBundles[].data`	사설 CA를 노드 신뢰 저장소에 추가 (base64)	앱 컨테이너의 trust store는 바뀌지 않음
`podSubnetSelectorTerms`	Pod IP를 노드와 다른 subnet에서 할당	`podSecurityGroupSelectorTerms`와 반드시 함께. namespace 단위가 아니라 NodeClass 단위
`podSecurityGroupSelectorTerms`	Pod 네트워크에 붙일 security group
`advancedNetworking.associatePublicIPAddress`	`false`면 노드에 공인 IP 없음	outbound 경로(NAT, endpoint)는 따로 필요

바꿀 수 없는 보안 기본값

IMDSv2, hop limit 1 고정

일반 Pod는 노드 메타데이터에 닿지 못합니다. hostNetwork Pod는 예외이니 앱 권한은 Pod Identity로 주고 리전 같은 값은 명시합니다.

SSH, SSM 접속 없음

관리형 Bottlerocket 변형, 읽기 전용 root 파일 시스템, SELinux enforcing. 노드에 들어가 고치는 운영은 불가

노드 역할은 최소 권한

WorkerNodeMinimalPolicy와 ContainerRegistryPullOnly. 앱 권한을 노드 역할에 넣지 않습니다.

최대 21일, 주간 AMI

패치는 새 AMI와 Drift로 들어옵니다. 오래된 노드가 남지 않는 대신 교체를 견디는 앱이 전제입니다.

taint와 label은 보안 경계가 아님: 배치를 나누는 도구입니다. 테넌트 격리가 필요하면 클러스터, 계정, 네트워크 정책 수준에서 나눕니다.

Spot, 예약 용량, 정적 풀

커스텀 풀이 필요

built-in 풀은 On-Demand만. 한 풀 안의 우선순위는 reserved, spot, on-demand이고, 배열 순서와 weight는 Spot 비율을 정하지 않습니다.

selector가 reserved를 뺄 수 있음

Pod의 capacity-type: on-demand nodeSelector는 예약 용량을 제외합니다. preferred affinity는 비율을 보장하지 않습니다.

NTH는 필요 없음

중단 처리는 내장입니다. Node Termination Handler DaemonSet과 SQS를 Auto Mode 노드에 두면 처리가 중복됩니다.

2분은 best effort

감지, eviction, 종료 처리가 시간을 씁니다. preStop: sleep 90은 예산 대부분을 소비하는 안티패턴입니다.

GPU와 EFA: 드라이버는 AWS, 사양은 사용자

requirements:
- key: eks.amazonaws.com/instance-gpu-manufacturer
  operator: In
  values: ["nvidia"]
- key: node.kubernetes.io/instance-type
  operator: In
  values: ["g5.2xlarge", "g5.4xlarge"]
taints:
- key: nvidia.com/gpu
  effect: NoSchedule
limits:
  nvidia.com/gpu: "4"
disruption:
  consolidationPolicy: WhenEmpty
  consolidateAfter: 10m

드라이버와 device plugin은 관리형

NVIDIA, Neuron 드라이버와 NVIDIA device plugin이 내장입니다. plugin은 DaemonSet으로 보이지 않고, amiFamily 지정도 없습니다.

유형	GPU	vCPU / RAM
g5.xlarge	A10G 1개	4 / 16 GiB
g5.2xlarge	A10G 1개	8 / 32 GiB
g5.12xlarge	A10G 4개	48 / 192 GiB

노드 전체 사양을 보세요

4 CPU, 16Gi를 요청하는 Pod는 시스템 예약 때문에 g5.xlarge에 들어가지 않습니다. GPU는 request와 limit을 같게 둡니다.

AZ 장애: ARC zonal shift

장애 AZ (shift 대상)새 노드 프로비저닝 중단. 그 AZ 노드의 consolidation, Drift 같은 voluntary disruption 중단

정상 AZ대체 용량은 여기서 뜹니다. 단, 대체 Pod가 장애 AZ에 의존하면 정상 AZ의 voluntary disruption도 멈춥니다.

사용자 설정클러스터의 zonal-shift-config를 켜면 끝. 플래그, IAM 변경 없음. autoshift는 ARC에서 따로

2026-07-10부터 Auto Mode 지원

ARC zonal shift 자체는 추가 요금이 없고, 대체 용량은 일반 요금입니다.

옮겨 주지 않는 것

단일 AZ EBS 볼륨, DoNotSchedule 같은 엄격한 AZ 제약은 그대로입니다. replica와 topology spread가 먼저입니다.

1.37 업그레이드: Karpenter가 먼저

1Karpenter 1.15.xkarpenter-crd와 controller chart를 함께, 버전 문자열은 1.15.0

2상태 확인EC2NodeClass ValidationSucceeded, 대시보드 label 변경

3컨트롤 플레인 1.37리전 기본은 1.36이라 버전 명시

4노드 AMI 갱신alias pin을 1.37 AMI로 바꾸면 Drift로 롤링, budget 적용

왜 Karpenter가 먼저인가: 1.37 호환 버전은 1.15.x뿐입니다. v1.14 LTS로는 1.36까지만 갈 수 있습니다.

SSH 없이 진단: 로그와 NodeDiagnostic

log type	무엇의 판단인가
`AUTO_MODE_COMPUTE_LOGS`	관리형 Karpenter: 프로비저닝, disruption
`AUTO_MODE_BLOCK_STORAGE_LOGS`	EBS CSI
`AUTO_MODE_LOAD_BALANCING_LOGS`	Load Balancer controller
`AUTO_MODE_IPAM_LOGS`	IP 주소 관리

CloudWatch Vended Logs로 전달

PutDeliverySource, PutDeliveryDestination, CreateDelivery 순서. 목적지는 CloudWatch Logs, S3, Firehose

control plane logging과 별개

api, audit 로그를 켜도 이 로그는 오지 않습니다. 따로 연결하고 전송, 보관 요금을 확인합니다.

무엇을 볼까: 이벤트와 메트릭

얼마나 흔들렸나

disruption이 Pod에 준 영향

karpenter_pods_disrupted_total

label: consolidation_policy, termination_mode

Balanced는 왜 승인했나

점수와 실행된 이동

karpenter_consolidation_score

karpenter_consolidation_moves_total

event: ConsolidationApproved

무엇이 막혔나

budget 여유와 실패

karpenter_nodepool_allowed_disruptions

karpenter_voluntary_disruption_queue_failures_total

karpenter_cloudprovider_errors_total

Auto Mode는 앞 장의 도구로

위 메트릭은 self-managed 기준입니다. Auto Mode는 COMPUTE 로그, NodeClaim, event로 봅니다. event source는 eks-auto-mode/compute

EC2 목록에서 기본 숨김

2026-04-22 이후 Auto Mode 인스턴스는 EC2 콘솔과 describe 목록에서 숨겨집니다. include-managed-resources로 조회

비용: 관리비는 할인되지 않는다

Spot이어도 관리비는 On-Demand 기준 금액 그대로
관리비는 인스턴스 유형별 시간당 고정 금액입니다. 12%는 On-Demand 가격과 나눈 계산값이고, Spot 가격과 나누면 비율이 훨씬 커집니다.

서울, 시간당	관리비	On-Demand	Spot (AZ별)	관리비 비율
m5.large	$0.01416	$0.118	$0.0195 ~ 0.0250	OD의 12%, Spot의 57 ~ 73%
m7g.large	$0.01204	$0.1003	$0.0194 ~ 0.0324	OD의 12%, Spot의 37 ~ 62%

그래도 합계는 Spot이 쌉니다: m5.large Spot + 관리비 $0.034 ~ 0.039 vs On-Demand + 관리비 $0.132. Spot 가격은 2026-10-21 조회값이며 수시로 바뀝니다.

노드 수

20

-

월 Auto Mode 관리비

-

월 On-Demand EC2

서울 리전 Price List API 단가, 월 730시간 가정의 계산 모델입니다.

인스턴스 유형과 시간 기준

EC2 요금과 별도로 부과, 초 단위 과금, 최소 1분

구매 옵션과 독립ⓘ

Spot, RI, Savings Plans 할인이 관리비를 줄이지 않습니다. Spot일수록 비율이 커집니다.

GPU 계열 인하 (2026-07-01)

G 계열 35%, P 계열과 Trainium 60% 인하. 조직 150노드 초과는 별도 문의

비용 귀속: 태그, 약정, 무엇이 할인되나

할인 수단	EC2 요금	Auto Mode 관리비
Compute Savings Plans	적용 (최대 66%)	미적용
EC2 Instance Savings Plans	적용 (최대 72%)	미적용
Reserved Instances	적용	미적용
Spot	Spot 가격 (SP 대상 아님)	미적용

클러스터별 귀속: aws:eks:cluster-name

AWS가 EC2 인스턴스에 붙이는 태그입니다. Billing에서 cost allocation tag로 활성화해야 보이고, control plane 요금은 포함하지 않습니다.

관리비만 보려면

Cost Explorer에서 usage type이 *EKS-Auto:*-management-hours인 항목으로 거릅니다.

NodePool, 팀 단위는 직접

NodeClass tags로 팀 태그를 붙이거나 Kubecost 같은 도구로 Pod requests 기준 배분합니다.

마이그레이션 1: 바뀌는 driver 이름

리소스	직접 설치한 controller	Auto Mode
StorageClass provisioner	`ebs.csi.aws.com`	`ebs.csi.eks.amazonaws.com`
Service `loadBalancerClass` (NLB)	`service.k8s.aws/nlb`	`eks.amazonaws.com/nlb`
IngressClass controller (ALB)	`ingress.k8s.aws/alb`	`eks.amazonaws.com/alb`
TargetGroupBinding, IngressClassParams	`elbv2.k8s.aws/v1beta1`	`eks.amazonaws.com/v1`
NodeClass	`karpenter.k8s.aws/v1` EC2NodeClass	`eks.amazonaws.com/v1` NodeClass

PVC는 넘어오지 않음

다른 provisioner의 볼륨은 마운트할 수 없습니다. snapshot 복원이나 Retain 후 static PV 재생성, AWS의 migration tool을 씁니다.

LB도 인수하지 않음

새 LB를 만들고 DNS로 blue/green 전환합니다. 기존 LB controller는 자기 리소스가 남아 있는 동안 유지합니다.

CoreDNS Deployment 유지

Auto Mode 노드는 node-local DNS를 씁니다. Auto가 아닌 노드가 남아 있는 동안 기존 CoreDNS를 지우지 않습니다.

마이그레이션 2: 노드를 옮기는 순서

1built-in 풀 없이 켜기nodePools: []. 무제한 general-purpose가 Pending Pod를 먼저 가져가지 않게

2NodeClass, 선택적 풀default NodeClass가 없으니 직접 만들고 EC2 access entry 추가. taint 건 풀

3wave별 이전Deployment, GitOps 원본에 toleration과 compute-type: auto selector. 저위험부터

4한 대씩 drain앱 검증 후 다음 노드. --force, --delete-emptydir-data로 오류를 덮지 않기

5비운 뒤 축소, 삭제기존 노드가 빈 것을 확인하고 desired 0, 삭제는 원래 IaC로

desired size 축소는 drain 단계가 아닙니다: 어떤 노드를 지울지 ASG가 고릅니다. 노드 그룹 전체를 지울 때는 AWS 기본 경로인 eksctl delete nodegroup이 노드를 drain한 뒤 삭제합니다.

Auto Mode인가, 직접 운영인가

직접 운영 쪽 신호

custom AMI, userData, launch template, SSH나 SSM 접속이 필요
kubelet, sysctl 요구가 advancedCompute 지원 필드를 벗어남
Windows 노드, DRA, 대체 CNI 필요 (Security Groups per Pod는 podSecurityGroupSelectorTerms로 대체)
feature gate 기능이나 FIS EC2 장애 주입 테스트가 필요

Auto Mode 쪽 신호

Karpenter minor마다 CRD와 breaking change를 따라갈 인력이 부족
CNI, CoreDNS, EBS CSI, LB controller 운영을 줄이고 싶음
주간 AMI 교체와 21일 수명 상한을 보안 기준으로 받아들일 수 있음
인스턴스당 관리비가 운영 시간 절감보다 작다고 판단

0

직접 운영 신호

0

Auto Mode 신호

왼쪽이 하나라도 필수라면: 그 워크로드는 self-managed가 맞습니다. 클러스터를 나누거나, 마이그레이션 중에만 NodePool로 분리해 공존합니다.