EKS Auto Mode 실전 도입 가이드

EKS Auto Mode가 나온 지 1년 반쯤 됐다. 초기엔 "AWS가 Karpenter 위에 껍데기 하나 씌운 거 아냐?"라는 반응이 많았는데, 올해 초부터 zonal shift, EFA 지원, CloudWatch 로깅까지 붙으면서 이제 진지하게 검토해볼 만한 옵션이 됐다.

우리 팀도 얼마 전에 스테이징 클러스터 하나를 Auto Mode로 옮겼다. 이 글은 그 과정에서 정리한 내용이다. "왜 쓰는지" 같은 마케팅 얘기는 최대한 빼고, 실제로 뭘 바꿔야 하고 뭘 조심해야 하는지에 집중한다.

뭘 대신 관리해주는지부터

Auto Mode를 켜면 AWS가 아래를 관리한다.

• 컴퓨트: Managed Node Group 대신 Karpenter가 노드를 띄운다. AMI는 Bottlerocket 고정, 21일마다 강제 재활용
• 네트워킹: VPC CNI, kube-proxy, CoreDNS를 AWS가 관리. 버전 업그레이드 자동
• 스토리지: EBS CSI driver 자동
• 로드밸런싱: AWS Load Balancer Controller가 built-in

즉 애드온 카탈로그 화면에서 눌러 깔던 것들이 전부 컨트롤 플레인 쪽으로 흡수된다. 대신 이 컴포넌트들은 SSH로 들어가서 만질 수 없고, 커스텀 설정도 제한된다. 이게 나중에 지뢰가 된다.

켜기 전 반드시 확인할 것

기존 클러스터에 Auto Mode를 켜는 건 API 콜 한 번이면 된다.

aws eks update-cluster-config \
  --name prod-cluster \
  --compute-config enabled=true,nodePools=general-purpose,system \
  --kubernetes-network-config elasticLoadBalancing={enabled=true} \
  --storage-config blockStorage={enabled=true}

근데 이 명령을 치기 전에 봐야 할 게 몇 가지 있다.

첫째, 기존 addon 충돌. vpc-cni, kube-proxy, coredns, aws-ebs-csi-driver, aws-load-balancer-controller 이 다섯 개가 클러스터에 addon이나 Helm으로 이미 깔려 있으면 Auto Mode가 관리하는 것과 충돌한다. Auto Mode를 켜기 전에 먼저 제거해야 한다. 우리는 이걸 놓쳐서 LB 컨트롤러가 두 개 떠서 인그레스가 이상하게 프로비저닝된 적이 있다.

둘째, DaemonSet. Auto Mode 노드는 21일마다 강제로 죽는다(정확히는 drift 발생 시 순차 교체). 로그 수집 에이전트나 시큐리티 에이전트 같은 DaemonSet이 있다면 노드 교체 주기에 대응하는지 확인해야 한다. Fluent Bit 같은 건 문제없지만, 자체 개발한 에이전트라면 초기화 시간이 노드 사이클보다 오래 걸리지 않는지 봐야 한다.

셋째, NodePool을 커스텀 정의할 것인가. Auto Mode 기본 NodePool(general-purpose, system)만 쓰면 인스턴스 타입 선택 로직이 AWS 손에 넘어간다. 우리는 GPU 워크로드나 ARM 노드를 명시적으로 원해서 커스텀 NodePool을 하나 더 정의했다.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: arm-workload
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: kubernetes.io/arch
          operator: In
          values: ["arm64"]
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
      expireAfter: 336h

여기서 NodeClass가 예전 EC2NodeClass 대신 eks.amazonaws.com/NodeClass로 바뀌었다는 점만 조심하면 된다. 나머지는 기존 Karpenter랑 거의 똑같다.

비용, 생각보다 미묘하다

Auto Mode는 EC2 인스턴스 요금에 12% 정도 관리 수수료가 얹힌다(GPU 인스턴스는 최근에 요금이 내려가서 지금은 훨씬 낮다). 이걸 보고 "그럼 비싸잖아"라고 반응하는 사람이 많은데, 실제로 계산해보면 좀 다르다.

우리 팀 기준으로 계산했을 때, 자체 Karpenter를 운영할 때 들어가던 시간(업그레이드 검증, Bottlerocket AMI 관리, 각종 addon 버전 매트릭스 관리)이 대략 매달 3-5일이었다. Auto Mode로 옮기면 12% 수수료가 그 인건비보다 싸다. 다만 대규모 클러스터(노드 100대+)는 절대 금액이 커지니까 계산을 다시 해봐야 한다.

최근 붙은 기능 두 개

올해 7월에 zonal shift 지원이 붙었다. AZ 하나에서 장애가 나면 ARC(Application Recovery Controller)가 해당 존의 노드로 트래픽이 안 가게 자동 처리한다. 예전엔 Karpenter 커스텀 컨트롤러 만들어서 처리하던 걸 알아서 해준다.

또 EFA(Elastic Fabric Adapter) 지원도 붙어서, ML 워크로드처럼 노드 간 저지연 통신이 필요한 경우도 Auto Mode에서 다룰 수 있게 됐다. 이건 아직 우리는 안 써봤다.

마이그레이션 순서

정리하면 이 순서로 진행하면 된다.

1. 스테이징 클러스터부터. 프로덕션은 최소 한 달 스테이징 검증 후
2. 위에서 언급한 5개 addon을 먼저 제거 (또는 conflict resolution 옵션으로 override)
3. Managed Node Group을 하나씩 taint 걸어서 워크로드 이전 유도
4. Karpenter가 새 노드 띄우는 걸 확인
5. 기존 노드 그룹 삭제
6. CloudWatch 로그에서 Karpenter 스케줄링 이벤트 확인 (2026년 2월 업데이트 이후 노출됨)

안 켜는 게 나은 케이스

혹시 아래 중 하나라도 해당하면 Auto Mode는 아직 미루는 게 낫다.

• 노드에 SSH 접속해서 강제로 뭘 해야 하는 상황이 정기적으로 발생 (디버깅, 커널 파라미터 튜닝)
• CNI를 Cilium이나 Calico로 갈아끼운 경우
• Bottlerocket이 지원 안 하는 특수 커널 모듈 필요

우리는 결국 대부분의 개발 클러스터를 Auto Mode로 옮겼지만, ML 학습용 클러스터는 자체 Karpenter로 남겼다. 상황 따라 다르다.

혹시 다른 팀에서 Auto Mode 도입하고 나서 예상 못 한 이슈 겪은 사례 있으면 댓글로 공유 부탁드린다.

---

태그: EKS, Auto Mode, Karpenter, AWS, Kubernetes, 클러스터운영