EKS Auto Mode 6개월, 한 번 더 같은 선택을 할까

작년 말에 우리 팀이 EKS Auto Mode로 갈아탔다. 정확히는 새로 만드는 서비스 클러스터 한 대를 Auto Mode로 띄워서 운영해본 게 6개월 정도 됐다. 기존 클러스터들은 Karpenter + 자체 노드 그룹으로 굴리고 있었고, 솔직히 큰 불만은 없었다. 그런데 신규 팀에서 클러스터를 자꾸 늘리는 상황이 되니까, 모든 클러스터마다 Karpenter 버전 맞추고, CoreDNS HPA 손보고, VPC CNI 업그레이드 줄 세우는 게 점점 부담이었다. "이거 AWS가 다 해주겠다는데 한번 맡겨보자"는 분위기였다.

6개월 동안 잘 굴러간 부분도 있고, 새벽에 멘탈이 나간 부분도 있어서 정리해둔다. 누가 똑같은 선택을 앞두고 있다면 이 글이 조금이라도 시간을 아껴주면 좋겠다.

도입 직후 — "이거 너무 편한데?"

처음 한 달은 정말 좋았다. 노드 그룹을 따로 만들 필요가 없고, Karpenter NodePool YAML을 들고 다닐 필요도 없다. 클러스터를 만들면 general-purpose라는 빌트인 노드 풀이 알아서 작동하고, GPU 워크로드를 올리면 system 풀과 별개로 따로 띄울 수도 있다.

특히 좋았던 건 VPC CNI, kube-proxy, CoreDNS, EBS CSI 같은 add-on들이 전부 빠져 있다는 점이다. 정확히는 빠진 게 아니라 컨트롤 플레인 쪽에 숨어 있는데, kubectl get pods -n kube-system 해보면 거의 텅 비어 있다. 업그레이드 PR 만들 일이 없다. 한 분기 동안 add-on 업그레이드 회의가 없어진 것만으로도 체감 가치가 컸다.

ALB 컨트롤러도 자동으로 떠 있다. 그냥 Ingress 만들면 ALB가 생긴다. EBS CSI도 PVC 만들면 볼륨이 붙는다. "이게 매니지드 쿠버네티스의 종착지인가" 싶은 순간들이 있었다.

첫 번째 삽질 — DaemonSet이 안 뜬다

문제는 보안팀에서 EDR 에이전트를 깔겠다고 했을 때 시작됐다. 우리가 쓰던 에이전트는 호스트의 /etc와 /var/log에 일부 파일을 쓰는 동작이 있었다. 기존 클러스터(Amazon Linux 2)에서는 멀쩡히 돌던 게, Auto Mode 노드에 올리니까 CrashLoopBackOff가 떴다.

Auto Mode 노드는 Bottlerocket 기반이다. 그리고 Bottlerocket은 루트 파일시스템이 read-only다. /etc에 쓸 수 없고, hostPath로 마운트할 수 있는 경로도 매우 제한적이다. 처음에는 "어 왜 안 되지" 하고 한참 헤맸는데, AWS 문서를 다시 읽어보니 Auto Mode에서 지원하지 않는 시나리오로 명시돼 있었다.

해결책은 두 가지였다. 벤더에 OS 호환성을 문의해서 Bottlerocket용 빌드를 받든지, 아니면 self-managed 노드 그룹을 따로 만들어서 EDR 필요한 워크로드만 거기로 보내든지. 우리는 후자를 택했는데, 그 순간 "그래서 자동화는 어디까지인가"라는 생각이 들기 시작했다.

# 결국 이렇게 hybrid로 굴리게 됐다
# 대부분은 Auto Mode 노드
# EDR/특수 DaemonSet 필요한 워크로드만 self-managed
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: legacy-edr
spec:
  template:
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: legacy-al2023
      taints:
      - key: workload-type
        value: edr-required
        effect: NoSchedule

두 번째 삽질 — Pod 110개 캡

이건 정말 예상 못 했다. Auto Mode 노드는 노드당 Pod 수가 110개로 하드코딩되어 있다. 기존에 c6i.4xlarge 쓰면서 노드당 200개씩 띄우던 워크로드를 그대로 옮겼더니, 같은 인스턴스 타입인데 노드 수가 거의 두 배로 늘어났다.

월말에 청구서 보고 깜짝 놀랐다. 데이터 플레인 자체 비용이 늘어난 건 어쩔 수 없는데, Auto Mode가 EC2 단가에 12% 프리미엄을 붙인다. 12%면 단일 클러스터에 월 수백만 원 단위가 그냥 새는 수준이다. 작은 클러스터에서는 티가 안 났는데, 대규모로 가면 무시 못 한다.

우리는 결국 인스턴스 타입을 더 작은 걸로 바꾸고, bin-packing이 더 잘 되는 방향으로 워크로드를 재조정했다. Pod 단위가 작으면 110개 캡이 큰 문제가 안 되지만, 메모리를 많이 쓰는 자바 애플리케이션 클러스터에서는 영 비효율적이었다.

세 번째 삽질 — Datadog 에이전트의 IMDSv2

이건 진짜 새벽 3시에 깨서 봤다. Datadog 에이전트가 갑자기 메타데이터를 못 읽기 시작해서 호스트 메트릭이 다 끊겼다.

원인은 Auto Mode 노드의 IMDSv2 hop limit이 1로 하드코딩되어 있다는 것. 컨테이너 안에서 IMDS를 부르려면 hop limit이 최소 2는 되어야 한다(노드 호스트 → Pod 네트워크). 기존 노드에서는 launch template으로 httpPutResponseHopLimit: 2를 설정했었는데, Auto Mode에서는 그게 안 된다.

Datadog 쪽 대응은 IRSA로 EC2 메타데이터 대신 STS 토큰을 쓰는 방향으로 바꾸는 거였다. 결국 모든 클러스터의 Datadog 설정을 손봐야 했고, 그 작업이 일주일 걸렸다.

비슷한 문제로 일부 AWS SDK 기본 동작도 안 먹는다. 코드에서 명시적으로 region을 지정하지 않으면 IMDS에서 읽어오는 동작을 하는데, 이게 컨테이너 안에서 안 되니까 region 지정을 빼먹은 마이크로서비스들이 줄줄이 깨졌다. "왜 갑자기 us-east-1로 가지?" 하는 알람들이 새벽에 쏟아졌다.

그래도 좋았던 점들

불평만 늘어놨는데, 6개월이 지나서도 Auto Mode를 안 쓰겠다는 결론은 아니다. 좋은 점들이 분명히 있다.

업그레이드 부담이 정말 거의 없다. 1.31에서 1.32로 가는 작업이 이번 분기에 있었는데, 기존 클러스터에서는 Karpenter, VPC CNI, CoreDNS, EBS CSI, ALB 컨트롤러를 다 손봐야 했다. Auto Mode 클러스터는 컨트롤 플레인 버전만 올리면 끝났다. 노드 롤링도 21일 만료 정책 덕분에 알아서 갈아치워졌다.

신규 팀이 클러스터를 빨리 띄울 수 있는 것도 큰 장점이었다. 다른 팀에서 "POC용으로 클러스터 하나 필요한데요"라고 했을 때, Auto Mode면 Terraform 30줄로 끝난다. 기존 방식이면 NodePool 정의, add-on 버전 매핑, IAM 역할까지 한 200줄은 됐다.

비용 12% 프리미엄도 운영 인력 시간으로 환산하면 그렇게 비싼지는 솔직히 모르겠다. 사람 한 명이 하루 한 시간씩 클러스터 업그레이드/장애 대응에 쓰던 시간이 줄어든다고 보면, 인력 비용이 더 클 수도 있다. 이건 팀 규모에 따라 다른 얘기다.

그래서 결론은

6개월 운영하고 내가 내린 결론은 이렇다.

Auto Mode를 쓰면 좋은 곳: 새로 만드는 클러스터, POC, 개발/스테이징 환경, 일반적인 웹 애플리케이션 워크로드. 특수한 DaemonSet 요구사항이 없고, 노드에 SSH 들어가서 디버깅할 일이 거의 없는 경우.

Auto Mode가 아직 안 맞는 곳: 보안 에이전트가 호스트에 깊게 접근해야 하는 클러스터, 노드당 고밀도로 Pod를 띄워야 하는 비용 민감한 클러스터, Cilium/Calico를 CNI로 써야 하는 환경, Windows 노드가 필요한 경우.

결국 hybrid로 가게 된다: 우리도 그렇게 됐다. 대부분의 워크로드는 Auto Mode로 두고, 특수 케이스만 self-managed로 빼는 구성. 이게 가장 현실적이었다.

다시 같은 선택을 할 거냐고 물으면, 그래도 한다. 다만 처음부터 "100% Auto Mode로 가겠다"는 환상은 버리고 들어갈 것 같다. hybrid가 종착지인 걸 인정하고 시작하면 마음이 편하다. 110 Pod 캡과 12% 프리미엄도 처음부터 계산에 넣고 인스턴스 사이징을 했을 거다.

혹시 도입 전이신 분 있으면, 자기 클러스터에서 도는 DaemonSet 리스트부터 한 번 쭉 봐보는 걸 추천한다. EDR, 로그 수집기, 메트릭 에이전트, 시크릿 동기화 도구 — 이 중에 hostPath로 뭔가 쓰는 게 있다면 Bottlerocket 호환성을 먼저 확인하시라. 도입하고 나서 깨닫는 것보다 훨씬 빠르다.

다음에는 Auto Mode 환경에서 Karpenter NodePool을 어떻게 hybrid로 굴리고 있는지, 그 IaC 패턴도 한번 정리해보려고 한다.