AWS EKS vs Vanilla k8s

EKS Hands On study 에 앞서 AWS EKS 와 Vanilla k8s 가 어떻게 다른지 이해하고 실습을 진행하려고 한다.

EKS가 AWS에서 제공하는 관리형 k8s 서비스라는 건 알고 있었지만 구체적으로 순수 쿠버네티스와 어떻게 다른지 깊게 알고 실습을 진행하는 것이 이번 스터디에서 좀 더 도움이 될 것 같다.

 

Vanilla k8s

사실 vanilla k8s 라는 단어를 처음 들어봤다. 찾아보니 별도의 커스터마이징 없이 순수 오픈소스 쿠버네티스를 직접 설치/운영하는 것을 가리키는 표현이었다.

이전 회사에서 k8s를 도입하기 위해서 Proxmox 기반 VM 3개를 생성한 뒤 하나는 control plane, 나머지 2개는 Worker node (Data plane)로 구성해 직접 설치해 본 경험이 있다. 현재 홈 서버에서는 kind (Kubernetes IN Docker) 기반으로 k8s를 직접 구축해서 사용 중인데, 이처럼 구성 방식에 관계 없이 직접 설치해서 운영하는 이런 방식을 통틀어서  Vanilla k8s 라고 하는 것 같다.

 

1. 컨트롤 플레인

구성요소

항목	EKS	Vanillak8s
API Server	AWS 완전 관리, Multi AZ 자동 구성	직접 설치, 직접 HA 구성(로드밸런서 필요)
etcd	AWS 완전 관리, 사용자 접근 불가	직접 설치, 백업/복구 직접 구성
Scheduler	AWS 관리, 커스텀 스케줄러 추가는 가능	직접 설치, 커스텀 스케쥴러 자유롭게 교체
Controller Manager	AWS 관리	직접 관리
Cloud Controller Manager	AWS CCM 자동 통합	필요시 직접 설치

 

가용성 (HA) 구성

EKS

• 컨트롤 플레인 노드 자체가 보이지 않음.
• AWS가 자동으로 Multi AZ 배포 및 복구
• etcd 백업 / 복구 AWS 책임

Vanilla k8s

• etcd 홀수 노드 클러스터 직접 구성
• API 서버 앞에 직접 LB 배치
• 장애 감지 및 복구 직접 처리

 

업그레이드

EKS

• 콘솔/eksctl에서 버전 선택 → 버튼 클릭
• 컨트롤 플레인만 먼저 업그레이드 (노드 그룹은 별도)
• 단, EKS 지원 버전만 사용 가능 (최신 K8s 버전보다 수개월 늦을 수 있음)

Vanilla k8s

• etcd 백업
• 컨트롤 플레인 노드 순차 업그레이드 (drain → upgrade → uncordon)
• kubeadm upgrade apply 직접 실행
• Version Skew 정책 직접 관리 (±1 마이너 버전)

 

접근제어 및 인증

EKS

• IAM + RBAC 이중 구조
• aws-auth ConfigMap 또는 EKS Access Entry로 IAM → K8s 권한 매핑
• IRSA (IAM Roles for Service Accounts): Pod 레벨 AWS 권한 부여
• EKS API 접근 자체도 IAM으로 제어

Vanilla k8s

• 순수 RBAC
• 자체 CA 인증서 직접 관리
• OIDC 직접 구성 (Dex, Keycloak 등)
• kubeconfig 직접 배포

 

2. 데이터 플레인

워커노드 구성

	EKS	Vanilla k8s
노드 프로비저닝	Managed Nodegroup, Fargate, Self Managed	직접 VM 생성 후 kubeadm join
kubelet	AWS 최적화 AMI에 포함	직접 설치 및 관리
컨테이너 런타임	containerd 기본 (1.24 +)	Docker/Containerd/CRI-O 자유선택
노드 OS	Amazon Linux 2/2023, Bottlerocket, Ubuntu	자유 선택
오토스케일링	Karpenter 또는 Cluster Autoscaler(CA)	Cluster Autoscaler 직접 설치

 

네트워크 (CNI)

EKS

• VPC CNI 기본
• Pod IP = 실제 VPC IP → VPC 내 다른 리소스와 직접 통신 가능
• 단점: 노드당 ENI/IP 개수 제한 = Pod 개수 제한
• Cilium, Calico를 VPC CNI 대신 사용 가능하나 추가 설정 필요

Vanilla k8s

• 자유 선택 (Calico / Flannel / Cilium / Weave)
• 네트워크 정책, 성능, 기능에 따라 CNI 자유롭게 선택
• 오버레이 네트워크로 클러스터 내부 IP 대역 독립 운영

 

스토리지

EKS

• EBS CSI Driver: 블록 스토리지, ReadWriteOnce
• EFS CSI Driver: 공유 파일시스템, ReadWriteMany
• FSx CSI Driver: 고성능 워크로드
• IRSA로 CSI 드라이버에 AWS 권한 자동 부여

Vanilla k8s

• CSI 드라이버 직접 설치 및 관리
• NFS, Ceph, Longhorn 등 자유롭게 선택
• StorageClass 직접 정의

 

로드밸런싱

EKS

Ingress → [MetalLB / nginx / HAProxy]
           └─ 온프레미스 LB 직접 구성
           └─ NodePort → 외부 LB 연동

Vanilla k8s

Ingress → [AWS Load Balancer Controller]
           └─ ALB (Application Load Balancer) 자동 생성
           └─ NLB (Network Load Balancer) 자동 생성
           └─ Ingress 어노테이션으로 AWS LB 옵션 제어

 

3. 핵심 요약

정리하면 Vanilla k8s 는 자유도가 높고 인프라 비용이 상대적으로 낮은 대신 운영 비용이 많이 든다. 

EKS는 운영 부담은 적은 대신에 OS 나 CNI 등에서 제약이 있으며, 인프라 유지 비용이 상대적으로 많이 소요된다.