딜라이트룸의 Amazon EKS Auto Mode를 활용한 멀티 클러스터 운영 효율화 사례

딜라이트룸은 Alarmy와 DARO를 운영하는 글로벌 앱 회사로, 2025년 11월 기존 5개 EKS 클러스터를 Amazon EKS Auto Mode로 전환한 뒤 현재는 10개 이상 클러스터를 모두 Auto Mode로 운영하고 있다.

기존 EKS 운영은 업그레이드 부담이 컸다. Control Plane을 올린 뒤에도 Add-on을 따로 맞춰야 했고, VPC CNI, kube-proxy, CoreDNS, EBS CSI driver, 노드, self-managed Karpenter까지 총 7개 컴포넌트를 개별 관리해야 했다. 특히 Karpenter는 v0.32.0의 CRD 변경과 v1.0.0의 스키마 변경을 거쳐 v1.1까지 가야 했고, 블루-그린 전환과 호환성 매트릭스 점검까지 겹치면서 클러스터당 4~6시간이 들었다. Auto Mode는 네트워킹·스토리지·컴퓨트를 AWS가 관리해 이 부담을 크게 줄였고, Shared Responsibility Model도 바꿔 고객이 직접 책임지던 Data Plane 관리와 AMI 패치가 AWS로 넘어갔다.

• Pulumi로 인플레이스 전환을 관리했고, Karpenter는 v1.1 업그레이드 대신 Helm release, CRD, SQS Interruption Queue를 정리한 뒤 Auto Mode를 켜는 우회 전략을 택했다. 기존 노드와 Pod는 유지되고 신규 스케일링만 잠시 멈춘 점을 활용해 트래픽이 적은 새벽 시간대에 약 1시간 이내로 전환을 마쳤다.
• 개발 환경에서는 karpenter.k8s.aws/*와 eks.amazonaws.com/* 레이블 차이를 먼저 확인해 nodeSelector와 toleration 충돌을 잡았고, 운영 전에는 기존 레이블을 쓰는 워크로드를 자동 식별해 수정했다.
• 관찰성은 CloudWatch Vended Logs와 NodeDiagnostic CRD로 보강했다. AUTO_MODE_COMPUTE_LOGS와 AUTO_MODE_IPAM_LOGS를 먼저 켠 뒤, NodePool 레이블(karpenter.sh/nodepool)이나 인스턴스 ID 기준으로 진단 로그를 모으는 Python 자동화 스크립트를 만들었고, karpenter.sh/do-not-disrupt로 consolidation을 막은 뒤 S3 pre-signed URL로 수집했다. 보존 기간은 30일로 설정했다.

초기에는 신규 노드에서 CoreDNS가 완전히 뜨기 전에 Pod가 실행되며 DNS 조회가 read: connection refused로 실패하는 race condition도 있었다. AWS Support와 함께 원인을 추적한 결과 특정 AMI 문제였고, 수정 AMI가 자동 반영되면서 해소됐다. 동시에 wait-for-dns init container를 넣어 재발 방어선을 추가했다.

도입 후 업그레이드 시간은 30분 이내로 줄었고, 직접 관리하던 컴포넌트는 7개에서 0개가 됐다. 반복적인 업그레이드와 진단 작업이 줄면서 소규모 인프라 팀이 여러 클러스터를 운영하기 훨씬 쉬워졌다.