[AEWS4기] EKS Auto mode

EKS 를 운영하다 보면 누구나 드는 생각이 있다. 아니 EKS를 도입하기 시작하는 시점부터 바라는 것.

인프라 운영의 자동화

이런 자동화를 도입하기 위해서 처음 K8s를 도입했고, managed service 인 EKS를 사용하지만, 생각보다 손이 많이 간다. 그래서 처음 re:invent 2024 에서 발표된 EKS Automode 는 사람들의 많은 기대를 받으면서 등장했다.

 

EKS Automode가 기존 EKS 운영과 어떤 부분이 다른지 비교 분석 해보았다.

 

배경

EKS 는 k8s의 Control plane을 AWS에서 관리해주는 managed service 다. 하지만 EKS를 사용하는 사람들은 Data plane의 영역마저도 관리해주는 서비스를 필요로 해왔다. 그 기대에 부응하기 위해 re:invent 2024 에서 처음 등장한 EKS Automode 이다.

 

Amazon EKS Auto Mode는 AWS에서 Kubernetes 클러스터 관리를 획기적으로 간소화하기 위한 새로운 기능이며 EKS 사용자들에게 클러스터 운영의 복잡성을 크게 줄이면서 Kubernetes의 강력한 기능은 최대한 활용할 수 있도록 설계가 되었습니다. 

 

아래 그림에서 기존 EKS 에서 사용자가 관리해야 했던 부분과, Auto mode에서 자동으로 관리되는 부분이 어떻게 되는지 잘 나타나 있다.

 

 

범위

EKS Automode는 어디까지 자동 관리형으로 제공하는가? 아래는 공식 문서에 나와 있는 자동화 범위이다.

컴퓨팅

• 노드
  • 사용자 개입없이 워크로드를 실행하는데 필요한 많은 서비스로 구성된 AMI를 자동 선택한다.
  • SELinux 적용 모드와 읽기 전용 루트 파일 시스템을 사용하여 AMI에서 파일 액세스를 잠금한다.
  • SSH 또는 SSM 접근을 차단함으로써 노드에 대한 직접적인 액세스를 방지한다.
  • NVIDIA 또는 Neuron GPU에 대한 별도의 커널 드라이버와 플러그인을 통해 고성능 GPU 워크로드를 지원한다.
  • EC2 스팟 인스턴스 중단 알림 및 EC2 인스턴스 상태 이벤트르 자동 처리한다.
• 오토스케일링
  • 오토 스케일링을 사용하는 EKS Auto Mode는 예약 불가능한 포드를 모니터링하고 새 노드를 배포하여 해당 포드를 실행할 수 있다. 워크로드가 종료되면 EKS Auto Mode는 노드가 더 이상 필요하지 않을 때 노드를 동적으로 중단 및 종료하여 리소스 사용을 최적화한다.
• 업그레이드
  • 노드를 제어하면 필요에 따라 보안 패치와 운영 체제 및 구성 요소 업그레이드를 제공하는 EKS Auto Mode의 기능이 간소화된다. 이러한 업그레이드는 워크로드 중단을 최소화하도록 설계되었다. EKS Auto Mode는 최신 소프트웨어 및 API를 보장하기 위해 최대 21일의 노드 수명을 적용한다.

로드밸런싱

EKS Auto Mode는 Amazon의 Elastic Load Balancing 서비스와 통합하여 Kubernetes 서비스 및 수신 리소스용 로드 밸런서의 프로비저닝 및 구성을 자동화함으로써 로드 밸런싱을 간소화한다. 애플리케이션과 Network Load Balancer 모두에 고급 기능을 지원하고, 수명 주기를 관리하며, 클러스터 수요에 맞게 확장한다. 이러한 통합은 AWS 모범 사례를 준수하는 프로덕션 지원 로드 밸런싱 솔루션을 제공하므로 인프라 관리가 아닌 애플리케이션에 집중할 수 있다.

 

스토리지

EKS Automode는 노드 종료시 볼륨 유형, 볼륨 크기, 암호화 정책, 삭제 정책을 설정하여 임시 스토리지를 구성한다.

 

네트워크

EKS Auto Mode는 포드 및 서비스 연결을 위한 중요한 네트워킹 작업을 자동화합니다. 여기에는 IPv4/IPv6 지원과 IP 주소 공간을 확장하기 위한 보조 CIDR 블록 사용이 포함됩니다.

ID & 액세스

EKS Auto Mode 클러스터에 EKS Pod Identity 에이전트를 설치할 필요가 없다.

 

 

한계점

 Custom VPC CNI 설정 불가

• aws-node DaemonSet 환경변수 직접 수정 불가
• ENIConfig CRD 기반 Custom Networking 불가
• 기존 SecurityGroupPolicy CRD 방식 SGPP 불가
• 대안: NodeClass의 podSubnetSelectorTerms, podSecurityGroupSelectorTerms로 동일 목적 달성 (2025.6 추가)

GPU Device Plugin 충돌 (MNG 하이브리드 필요)

• 기본 GPU(NVIDIA, Neuron)는 지원되나 AWS 기본 Device Plugin 강제 사용
• NVIDIA GPU Operator, MIG, Time-slicing 등 고급 설정 충돌
• 특정 CUDA/드라이버 버전 고정 불가
• 대안: GPU 워크로드는 MNG로 분리

io2 Block Express 미지원

• Auto Mode EBS CSI provisioner(ebs.csi.eks.amazonaws.com)는 gp3, io1, sc1, st1만 지원
• 대용량/초저지연 DB (SAP HANA 등) 부적합
• 대안: 표준 EBS CSI 별도 설치 (관리 복잡도↑)

EFS/FSx CSI 별도 설치 필요

• 기본 제공은 EBS CSI 뿐
• EFS, S3 Mountpoint는 EKS add-on 설치 가능 (단, 자동 업그레이드 대상 아님)
• FSx for Lustre/NetApp ONTAP/OpenZFS는 self-managed로 설치

Custom CoreDNS 설정 제한

• CoreDNS Deployment 자체가 없음 (각 노드의 system service로 실행)
• kube-system/coredns ConfigMap 수정 불가
• Corefile 커스터마이징(stub-domain, forward, rewrite 등) 불가
• Auto Mode + non-Auto Mode 혼용 시 기존 CoreDNS Deployment 유지 필요

노드 SSH/SSM 접근 제한

• 공식 문서상 SSH와 SSM 모두 차단 (disallowing SSH or SSM access)
• 디버깅 대안: kubectl debug node/, NodeDiagnostic 리소스, CloudWatch Logs, EC2 console output

EC2 인스턴스 직접 관리 불가

• "EC2 Managed Instance" 카테고리 — AWS가 라이프사이클 전담
• Custom AMI 불가, User data/bootstrap 주입 불가
• 콘솔에서 stop/start/terminate 직접 불가 (NodeClaim 삭제로만)
• IMDSv2 강제, hop limit 1 고정
• 노드 최대 수명 21일 (자동 재생성) → PDB 필수