kubectl get nodes를 처음 EKS 클러스터에서 쳐본 사람은 잠시 멍해진다. 컨트롤 플레인이 어디 있는지, 노드가 왜 갑자기 두 개씩 떴는지, Pod가 ENI를 한 칸씩 잡아먹는 이유가 뭔지 — 매니지드 K8s를 쓴다고 해서 K8s가 사라지는 건 아니다. 다만 etcd 백업이나 컨트롤 플레인 패치처럼 운영의 가장 흉한 부분이 AWS 쪽으로 넘어갈 뿐이다. SAP 시험은 이 "남은 부분"을 정확히 짚어낸다. Managed Node Group의 자동 드레인이 어떻게 동작하는지, IRSA가 STS의 어떤 API를 부르는지, Karpenter가 ASG를 안 거치고 EC2를 어떻게 만드는지가 한 도메인에 두세 문제씩 깔린다.
이 글에서는 EKS의 데이터 플레인을 세 층으로 쪼개서 본다. 노드를 어떻게 띄우는가(노드 그룹), Pod에 어떻게 권한을 주는가(IRSA·Pod Identity), 수요에 맞춰 노드를 어떻게 자동 조정하는가(Karpenter). 여기에 VPC CNI·EBS CSI 같은 Addon이 어떻게 매니지드 형태로 들어오는지를 곁들인다. 어제 그린 ECS·EKS·Fargate 지도가 EKS 안으로 들어와서 어떻게 채워지는지를 보는 시간이다.
EKS 클러스터 하나에는 노드 그룹을 여러 개 섞어서 붙일 수 있다. 종류는 셋이고, 차이는 "AWS가 어디까지 책임지는가"로 갈린다.