딜라이트룸, EKS Auto Mode로 멀티 클러스터 운영 효율 UP!
딜라이트룸은 EKS Auto Mode 전환을 통해 클러스터 업그레이드(Cluster Upgrade) 시간 90% 단축 및 운영 효율성을 향상시킴
기존 7개 컴포넌트 개별 관리에서 Control Plane 업그레이드(Control Plane Upgrade) 한 번으로 단순화
Karpenter 제거 후 EKS Auto Mode 활성화하는 우회 전략(Workaround Strategy)을 통해 마이그레이션 성공
CloudWatch Vended Logs 및 NodeDiagnostic CRD를 활용한 옵저버빌리티(Observability) 체계 구축
EKS Auto Mode 전환 배경: 업그레이드 복잡성 해결
딜라이트룸은 기존 EKS 클러스터 업그레이드 시 7개의 컴포넌트(Components)를 개별 관리해야 하는 어려움을 겪었다. 특히, Karpenter, VPC CNI, kube-proxy 등 Add-on 간의 호환성 매트릭스(Compatibility Matrix) 관리의 어려움이 컸다. Self-managed Karpenter의 Helm Chart 배포 및 SQS Interruption Queue 등 부수 인프라 관리 부담도 존재했다. 이러한 복잡성으로 인해 블루-그린(Blue-Green) 방식을 택하여 이중 운영 비용(Dual Operation Cost)과 DNS/트래픽 전환 작업에 많은 시간과 비용을 소모했다. EKS Auto Mode는 이러한 업그레이드 프로세스를 Control Plane 업그레이드 한 번으로 단순화하여 운영 효율성을 높였다.
Karpenter 제거 후 EKS Auto Mode 전환 전략
딜라이트룸은 Karpenter v0.3x와 v1.0x 버전 혼용으로 인해 공식 마이그레이션 가이드(Migration Guide)를 따르기 어려웠다. Karpenter v1.1 이상을 요구하는 EKS Auto Mode 전환을 위해, 딜라이트룸은 Karpenter를 일시적으로 제거하는 우회 전략을 선택했다. 이 전략은 Karpenter 제거 시 기존 노드와 Pod에는 영향이 없다는 점을 활용하여, 트래픽이 적은 새벽 시간대에 진행되었다. Karpenter 제거(Karpenter Removal) 후 EKS Auto Mode 활성화, Managed Karpenter 자동 구성으로 1시간 이내에 마이그레이션을 완료했다. 이로써 Karpenter 업그레이드 단계를 건너뛰고 마이그레이션 리스크(Migration Risk)를 최소화했다.
EKS Auto Mode 환경에서의 옵저버빌리티 확보
EKS Auto Mode는 SSH나 SSM을 통한 직접 접근이 제한되므로, 딜라이트룸은 상시 모니터링(Continuous Monitoring)과 사후 진단(Post-Diagnosis)을 병행하는 옵저버빌리티 체계를 구축했다. CloudWatch Vended Logs를 통해 Karpenter 및 VPC CNI의 로그를 수집하고, NodeDiagnostic CRD를 활용하여 노드 단위의 시스템 로그를 수집했다. NodeDiagnostic 자동화를 위해 자체 Python 스크립트를 개발하여, 노드 진단 로그 수집을 단일 명령어로 수행할 수 있도록 했다. 이 스크립트는 Karpenter NodePool 레이블을 기반으로 노드를 일괄 수집하거나, 특정 인스턴스 ID를 지정하여 개별 노드를 수집하는 기능을 제공한다. 또한, Karpenter consolidation을 방지하기 위해 do-not-disrupt 어노테이션(Annotation)을 활용했다.
nodeSelector/toleration 불일치 문제 해결
개발 환경 클러스터 전환 과정에서 EKS Auto Mode 노드의 레이블 체계(Labeling System) 불일치로 인한 스케줄링 실패(Scheduling Failure) 문제가 발생했다. EKS Auto Mode의 Managed Karpenter는 Self-managed Karpenter와 다른 레이블 체계를 사용하며, karpenter.k8s.aws/ 접두사 대신 eks.amazonaws.com/ 접두사를 사용한다. 딜라이트룸은 전체 워크로드의 nodeSelector와 toleration을 수동 점검하고, 기존 karpenter.k8s.aws/ 접두사 레이블을 참조하는 워크로드를 자동으로 식별하는 스크립트를 작성했다. 식별된 워크로드는 EKS Auto Mode의 레이블 체계에 맞게 수정하여 운영 환경 전환 시 스케줄링 문제를 예방했다. 이 경험을 통해 개발 환경에서의 사전 테스트(Pre-Testing)의 중요성을 강조했다.
EKS Auto Mode 도입 성과: 운영 효율성 및 보안 강화
EKS Auto Mode 도입 후 딜라이트룸은 클러스터 업그레이드 시간을 기존 4~6시간에서 30분 이내로 단축했다. 또한, Self-managed Karpenter 운영에 필요한 부수 인프라를 AWS 관리 영역으로 흡수하여 운영 부담을 줄였다. 클러스터 스케일링 능력 또한 향상되어, 5개에서 10개 이상의 클러스터로 확장되었으며, 신규 클러스터 구축 시간을 3~4시간에서 30분 이내로 단축했다. 보안 측면에서는 EKS Auto Mode의 기본 Node Role인 AmazonEKSWorkerNodeMinimalPolicy를 사용하여 불필요한 권한을 제거하고, 21일의 노드 자동 교체를 통해 CVE 및 보안 패치를 신속하게 반영하는 체계를 갖추었다. 이러한 변화는 딜라이트룸이 비즈니스 워크로드(Business Workload)에 집중할 수 있는 환경을 조성했다.