[EKS] EKS: Overview
서종호(가시다)님의 AWS EKS Workshop Study(AEWS) 1주차 학습 내용을 기반으로 합니다.
TL;DR
이번 글에서는 EKS의 핵심 개념과 아키텍처를 다룬다.
- 정의: AWS가 컨트롤 플레인을 완전 관리하는 Kubernetes 서비스
- 아키텍처: 컨트롤 플레인(AWS 관리) + 데이터 플레인(사용자 관리) 분리 구조
- 데이터 플레인: 관리형 노드 그룹, 자체 관리형 노드, Fargate, EKS Auto Mode 네 가지 방식
- 온프레미스와의 차이: 컨트롤 플레인 관리 부담이 사라지고, 컴퓨팅·네트워킹·보안의 관리 책임 경계가 달라짐
들어가며
On-Premise K8s Hands-on Study에서는 Kubernetes 클러스터를 직접 구성하고 운영했다. The Hard Way로 모든 구성 요소를 손으로 설치했고, kubeadm으로 부트스트래핑을 자동화했고, Kubespray로 OS 설정부터 클러스터 구성까지 전체를 자동화했고, RKE2로 단일 바이너리 배포판을 경험했다.
이번에는 EKS(Elastic Kubernetes Service)다. 지금까지의 도구들은 자동화 수준이 달랐을 뿐, 결국 컨트롤 플레인을 사용자가 직접 관리했다. etcd를 직접 구성하고, API 서버 인증서를 직접 갱신하고, 컨트롤 플레인 노드의 장애 복구를 직접 해야 했다. EKS는 이 컨트롤 플레인 관리를 AWS가 완전히 맡는 관리형 서비스다. 사용자는 데이터 플레인(워커 노드)과 워크로드에 집중한다.
온프레미스 환경에서 직접 구성하던 것들이 EKS에서는 어떻게 달라지는지, 그리고 새롭게 알아야 할 것은 무엇인지 살펴보자.
EKS란
공식 문서 살펴보기
AWS 공식 문서를 보면, EKS를 다음과 같이 소개한다.
Amazon Elastic Kubernetes Service(Amazon EKS)는 Amazon Web Services(AWS) 클라우드와 자체 데이터 센터 모두에서 Kubernetes 클러스터를 실행하는 데 있어 최적의 플랫폼입니다.
Amazon EKS는 Kubernetes 클러스터의 구축, 보안 및 유지 관리를 간소화합니다.
핵심은 “Kubernetes 클러스터의 구축, 보안 및 유지 관리를 간소화”하는 것이다.
정의
EKS(Elastic Kubernetes Service)는 AWS가 Kubernetes 컨트롤 플레인을 완전 관리하는 관리형 Kubernetes 서비스다. “Elastic”은 AWS 서비스 네이밍에서 반복되는 키워드로(EC2, ELB, EBS 등), 수요에 따라 리소스를 탄력적으로 확장·축소할 수 있음을 나타낸다. EKS에서는 데이터 플레인의 노드 수를 워크로드에 맞춰 동적으로 조절하는 것이 이에 해당한다. Kubernetes 호환 인증(CNCF Certified Kubernetes)을 받았으므로, 리팩터링 없이 Kubernetes 호환 애플리케이션을 배포하고 커뮤니티 도구 및 플러그인을 사용할 수 있다.
EKS 사용과 관련된 두 가지 주요 접근 방식은 다음과 같다.
| 방식 | AWS가 관리하는 범위 |
|---|---|
| EKS 표준 | 컨트롤 플레인만 관리. 노드 관리, 워크로드 스케줄링, AWS 통합은 사용자가 처리 |
| EKS Auto Mode | 컨트롤 플레인 + 데이터 플레인(노드)까지 관리. 인프라 프로비저닝, 컴퓨팅 인스턴스 선택, 동적 스케일링, OS 패치를 자동 처리 |
온프레미스와의 비교
온프레미스 스터디에서 직접 관리했던 것들이 EKS에서는 어떻게 달라지는지 비교하면, EKS가 제공하는 가치가 분명해진다.
| 항목 | 온프레미스 (직접 관리) | EKS |
|---|---|---|
| 컨트롤 플레인 | etcd, API Server, Controller Manager, Scheduler 직접 설치·운영 | AWS가 완전 관리 (HA 기본, 자동 복원) |
| 인증서 | 직접 생성·갱신 (The Hard Way), kubeadm 자동화 | AWS가 관리 |
| etcd | 직접 구성·백업·복구 | AWS가 관리 (3개 AZ에 분산) |
| 노드 프로비저닝 | VM 직접 생성, OS 설정, kubelet 설치 | 관리형 노드 그룹 등 여러 방식 제공 |
| 네트워킹 | CNI 직접 선택·설치 (Flannel, Calico 등) | VPC CNI 기본 제공 (Pod에 VPC IP 직접 할당) |
| 업그레이드 | 컨트롤 플레인 + 노드 전부 수동 | 컨트롤 플레인은 API 한 번, 노드는 롤링 업데이트 |
| 보안 | 모든 보안 설정 직접 관리 | AWS와 사용자 간 공동 책임 모델 |
컨트롤 플레인 관리 부담이 사라지는 것이 가장 큰 변화다. 온프레미스에서 etcd 백업·복구, 인증서 갱신, API 서버 HA 구성 등에 들이던 노력을 워크로드 운영에 집중할 수 있다.
EKS 아키텍처
EKS 아키텍처는 크게 컨트롤 플레인, 컴퓨팅(데이터 플레인), 기능(EKS Capabilities) 세 축으로 구성된다.
위 그림은 EKS Standard와 EKS Auto Mode의 관리 경계를 보여준다. EKS Standard에서는 AWS가 컨트롤 플레인만 관리하고, EKS Add-Ons(CNI, EBS CSI Driver, Load Balancer Controller 등)와 EC2 인스턴스는 고객 계정에서 관리한다. EKS Auto Mode에서는 이러한 기능들이 Managed Capabilities로 EKS 관리 범위에 포함되어, 고객은 EC2 인스턴스와 Supporting AWS Services만 관리하면 된다.
컨트롤 플레인
Amazon EKS는 모든 클러스터가 고유한 Kubernetes 컨트롤 플레인을 보유하도록 보장한다. 클러스터 간 인프라가 완전히 분리되어 중복이 발생하지 않는다.
| 특성 | 설명 |
|---|---|
| 분산 구성 | AWS 리전 내 가용 영역 3개에 걸쳐 최소 2개의 API 서버 인스턴스와 3개의 etcd 인스턴스를 배치 |
| 최적 성능 | 컨트롤 플레인 인스턴스를 능동적으로 모니터링 및 조정 |
| 복원력 | 인스턴스가 불안정해지면 필요 시 다른 가용 영역을 사용하여 신속하게 대체 |
| 일관적 가동 시간 | 여러 가용 영역에서 실행하여 API 서버 엔드포인트 가용성 SLA 달성 |
온프레미스에서 etcd 3대를 직접 구성하고, API 서버를 로드밸런서 뒤에 배치했던 것을 AWS가 자동으로 처리해 준다. 컨트롤 플레인 구성 요소 간 트래픽은 Amazon VPC로 제한되며, Kubernetes RBAC 정책에 의해 접근이 제어된다.
컴퓨팅 (데이터 플레인)
컨트롤 플레인 외에 클러스터에는 노드라고 하는 워커 컴퓨터 세트가 있다. EKS에서 데이터 플레인을 구성하는 방식은 네 가지다.
| 데이터 플레인 방식 | 핵심 | 적합한 환경 |
|---|---|---|
| 관리형 노드 그룹 | EC2 인스턴스를 ASG로 묶어 EKS가 수명 주기 관리. 노드 패치, 업데이트, 스케일링을 AWS가 처리 | 대부분의 워크로드 (기본 선택지) |
| 자체 관리형 노드 | EC2 인스턴스를 완전히 제어. 노드 관리, 스케일링, 유지 관리를 사용자가 담당 | 커스텀 AMI, 특수 bootstrap 등 세밀한 제어 필요 시 |
| Fargate | 파드 단위 서버리스 컴퓨팅. 노드를 관리할 필요 없이 리소스 요구사항만 지정 | 노드 관리 불필요, 보안 격리 중요 시 |
| EKS Auto Mode | 데이터 플레인까지 AWS 관리를 확장. 내부적으로 Karpenter 기반으로 컴퓨팅 오토스케일링, 네트워킹, GPU 지원 등을 자동 처리 | 운영 오버헤드 최소화, 인프라 관리 위임 |
노드 오토스케일링 도구로는 ASG 기반의 Cluster Autoscaler와 EC2 API를 직접 호출하는 Karpenter가 있다. Karpenter는 노드 프로비저너로, 관리형/자체 관리형 노드 그룹과 함께 사용하거나, EKS Auto Mode의 내부 엔진으로 동작한다. 각 방식의 상세한 비교와 오토스케일링 도구의 역할 분담은 데이터 플레인 컴퓨팅 글에서 다룬다.
EKS 기능
EKS는 Kubernetes API를 클러스터에 설치하면서, 컨트롤러 및 기타 구성 요소를 EKS에서 완전하게 관리한다. 자동화된 패치 적용, 조정 및 모니터링을 제공하여 클러스터 내 서비스 운영 부담을 줄인다.
| 기능 영역 | 설명 |
|---|---|
| 관리 인터페이스 | AWS Console, EKS API/SDK, CDK, AWS CLI, eksctl, CloudFormation, Terraform 등 다양한 프로비저닝·관리 인터페이스 제공 |
| 액세스 제어 | Kubernetes RBAC과 AWS IAM을 결합한 액세스 관리. IAM 사용자/역할에 Kubernetes API 접근 권한 부여 |
| 컴퓨팅 | 모든 범위의 Amazon EC2 인스턴스 유형과 Nitro, Graviton 등 AWS 혁신 기술 활용 |
| 스토리지 | EBS, EFS, FSx, S3 등을 CSI 드라이버로 연동. EKS Auto Mode에서는 EBS 스토리지 클래스 자동 생성 |
| 보안 | 공동 책임 모델, 인프라 보안, Kubernetes 보안 |
| 모니터링 | 관찰성 대시보드, Prometheus, CloudWatch, CloudTrail, ADOT Operator |
| K8s 호환성 | Kubernetes 호환 인증 보유. 표준 지원과 확장 지원 제공 |
| 클러스터 기능 | ACK(Kubernetes API로 AWS 리소스 관리), Argo CD(GitOps), kro(리소스 오케스트레이션) 등 관리형 기능 |
온프레미스에서 CNI, CoreDNS, metrics-server 등을 직접 설치했던 것과 비교하면, EKS에서는 이들이 EKS 애드온으로 관리된다. Terraform에서 addons 블록으로 선언하면 EKS가 설치·업데이트를 처리해 준다.
EKS 요금
EKS 요금 구조는 다음과 같다.
| 과금 항목 | 설명 |
|---|---|
| EKS 클러스터 | Kubernetes 클러스터 버전 지원에 따라 클러스터당 시간 요금 |
| EC2 인스턴스 | 워커 노드로 사용하는 인스턴스 비용 |
| EBS 볼륨 | 워커 노드의 루트 볼륨 및 PV용 볼륨 |
| 네트워크 | 퍼블릭 IPv4 주소, NAT Gateway, 데이터 전송 등 |
| EKS Auto Mode | Auto Mode 사용 시 별도 요금 |
컨트롤 플레인에 대한 과금이 있다는 점이 온프레미스와의 차이다. 온프레미스에서는 컨트롤 플레인 노드의 하드웨어 비용만 있었지만, EKS에서는 AWS가 관리해 주는 대가로 클러스터당 시간 요금이 발생한다. 관리형 노드 그룹이나 Fargate 등 데이터 플레인 방식에 따라 추가 비용 구조가 달라진다.
결론
온프레미스에서 직접 etcd를 구성하고 인증서를 갱신하던 것이 EKS에서는 AWS가 처리해 준다. 편해지는 만큼, 쿠버네티스 그 자체에 대한 이해와 함께 AWS IAM과 Kubernetes RBAC의 통합, VPC 네트워킹과 Pod 네트워킹의 관계, 공동 책임 모델에서의 보안 경계 등 관리형 서비스 특유의 새로운 개념도 새롭게 알아야 한다.
Kubespray Overview에서 자동화 도구의 블랙박스 위험을 이야기했는데, 관리형 서비스는 그 추상화 수준이 한 단계 더 높다. 컨트롤 플레인이 보이지 않는다는 것은, 그 안에서 일어나는 일을 더 의식적으로 파악해야 한다는 뜻이다. 앞으로는 클러스터 배포·운영 과정에서 AWS가 무엇을 대신하고, 사용자에게 무엇이 남는지를 하나씩 짚어 나가 보고자 한다.
댓글남기기