클라우드 관리형 K8s(EKS, GKE, AKS)의 컨트롤 플레인 아키텍처 차이점
온프레미스에서 쿠버네티스를 운영할 때 가장 큰 부담은 컨트롤 플레인(Control Plane)과 etcd 클러스터의 고가용성(HA)을 유지하는 것입니다. 이를 해결하기 위해 퍼블릭 클라우드 벤더들은 컨트롤 플레인의 관리를 대신해주는 관리형 쿠버네티스 서비스(EKS, GKE, AKS)를 제공합니다. 사용자 입장에서는 단순히 "API 서버 엔드포인트" 하나만 제공받는 것처럼 보이지만, 그 이면을 들여다보면 각 클라우드 벤더의 인프라 철학과 네트워크 아키텍처에 따라 컨트롤 플레인을 구성하고 격리하는 방식이 완전히 다릅니다. 이 가이드에서는 AWS EKS, GCP GKE, Azure AKS의 컨트롤 플레인 내부 아키텍처 차이점을 심층 분석합니다.

1. AWS EKS (Elastic Kubernetes Service): 철저한 격리와 단일 테넌트 아키텍처
AWS EKS의 컨트롤 플레인 설계 철학은 "완벽한 격리(Isolation)"와 "단일 테넌트(Single-Tenant)"입니다. AWS는 보안과 가용성을 극대화하기 위해 다른 사용자와 인프라를 공유하지 않는 독립적인 컨트롤 플레인을 프로비저닝합니다.
- 인프라 구성: EKS 클러스터를 생성하면, AWS는 사용자의 VPC가 아닌 AWS가 관리하는 숨겨진 'EKS 관리형 VPC'에 컨트롤 플레인 노드들을 프로비저닝합니다. 이 공간에는 최소 2개 이상의 Kube-apiserver 인스턴스와 3개의 etcd 인스턴스가 3개의 가용 영역(AZ, Availability Zone)에 분산 배치됩니다.
- 네트워크 통신 (ENI 주입): 컨트롤 플레인(AWS 관리 VPC)과 워커 노드(사용자 VPC)는 물리적으로 분리되어 있습니다. EKS는 이 둘을 연결하기 위해 사용자의 VPC 서브넷에 EKS 컨트롤 플레인과 통신할 수 있는 특수한 탄력적 네트워크 인터페이스(Cross-account ENI)를 강제로 주입합니다. 워커 노드의 Kubelet은 이 ENI를 통해 API 서버와 통신합니다.
- etcd 관리: EKS는 각 클러스터마다 전용 etcd 클러스터를 독립적으로 구성합니다. 암호화는 AWS KMS와 깊게 통합되어 있으며, 디스크 볼륨 레벨의 암호화뿐만 아니라 쿠버네티스 시크릿(Secret)에 대한 봉투 암호화(Envelope Encryption)를 완벽하게 지원합니다.
- 가용성 및 프로비저닝: 단일 테넌트로 완전한 HA 클러스터를 구성하기 때문에, 클러스터 생성 속도가 상대적으로 느립니다(보통 10~15분 소요). 하지만 장애 격리 수준은 3사 중 가장 높습니다.
2. GCP GKE (Google Kubernetes Engine): Borg 기반의 극단적인 효율성과 속도
쿠버네티스의 본가인 Google이 만든 GKE는 자신들의 내부 컨테이너 오케스트레이션 시스템인 'Borg' 인프라 위에서 컨트롤 플레인을 실행합니다. GKE의 핵심은 효율적인 리소스 공유와 압도적인 관리 편의성입니다.
- 인프라 구성 (Zonal vs Regional): GKE는 두 가지 컨트롤 플레인 아키텍처 옵션을 제공합니다. 'Zonal 클러스터'는 단일 가용 영역에 1대의 컨트롤 플레인을 배치하며(주로 테스트용), 'Regional 클러스터'는 3개의 가용 영역에 컨트롤 플레인을 다중화하여 프로비저닝합니다.
- 마스터 노드 아키텍처: GKE의 컨트롤 플레인은 Google의 내부 Borg 인프라에서 특수한 컨테이너 형태로 실행됩니다. 즉, EKS처럼 무거운 가상 머신(VM)을 통째로 띄우는 것이 아니라, 거대한 공유 풀 안에서 논리적으로 격리된 컨트롤 플레인 프로세스를 실행합니다. 이 때문에 클러스터 생성 속도가 3사 중 가장 빠릅니다(수 분 이내).
- 네트워크 아키텍처: GKE 마스터 노드(컨트롤 플레인)는 Google이 소유한 섀도(Shadow) VPC에 위치하며, 사용자의 VPC 네트워크와 'VPC 네트워크 피어링(VPC Network Peering)'을 맺어 통신합니다. AWS의 ENI 주입 방식과 달리, 서브넷 대역을 라우팅 테이블로 연결하는 방식입니다.
- etcd 및 자동화: Google 인프라에 최적화된 내부 스토리지 메커니즘을 사용합니다. 컨트롤 플레인의 자동 업그레이드(Auto-upgrade)와 노드 자동 복구 기능이 3사 중 가장 성숙하고 공격적으로 동작하여, 운영자의 개입을 극단적으로 최소화합니다.
3. Azure AKS (Azure Kubernetes Service): 비용 효율성과 유연한 통합
Azure AKS는 무료 컨트롤 플레인 계층을 제공하며(유료 SLA 계층 별도 존재), Azure의 다른 엔터프라이즈 인프라 서비스와 매끄럽게 통합되는 것을 목표로 합니다.
- 인프라 구성: AKS 역시 Azure가 관리하는 숨겨진 구독(Subscription) 및 가상 네트워크(VNet) 리소스 그룹에 컨트롤 플레인을 구성합니다. 기본적으로 'Free Tier'를 선택하면 가용성을 보장하지 않는 가벼운 형태의 컨트롤 플레인이 제공되며, 프로덕션용 'Standard Tier'를 선택해야만 가용 영역(AZ)에 걸쳐 다중화된 API 서버와 etcd가 Uptime SLA(99.95%)와 함께 제공됩니다.
- 네트워크 통합: AKS는 기본
kubenet과Azure CNI두 가지 네트워크 모델을 제공합니다. Azure CNI를 사용할 경우, 파드가 가상 네트워크(VNet)의 IP를 직접 할당받아 VNet 상의 다른 Azure 리소스(DB, VM)와 복잡한 라우팅 없이 네이티브하게 통신할 수 있다는 강력한 장점이 있습니다. 컨트롤 플레인과 워커 노드는 Azure 내부 백본을 통해 보안 통신을 수행합니다. - API 서버 아키텍처: AKS는 최근 컨트롤 플레인의 확장성을 높이기 위해 아키텍처를 대폭 개선했습니다. 트래픽 부하에 따라 Kube-apiserver의 크기를 동적으로 확장(Scale-up/out)하는 반응성이 매우 우수합니다.
- Private Cluster 구조: 클러스터를 퍼블릭 인터넷에서 숨기는 Private Cluster를 구성할 때, AKS는 'Azure Private Link'를 사용하여 사용자 VNet의 프라이빗 엔드포인트(Private Endpoint)를 컨트롤 플레인에 연결합니다.
4. 컨트롤 플레인 핵심 아키텍처 비교 요약
4.1. 과금 모델과 SLA
- EKS: 클러스터당 고정 시간당 요금(월 약 $73)이 부과됩니다. 99.95%의 SLA를 보장하며, 컨트롤 플레인 비용을 끌어내릴 수 있는 무료 티어는 없습니다.
- GKE: Regional 클러스터는 EKS와 비슷한 비용이 발생하지만, Zonal 클러스터에 한해 계정당 1개의 무료 컨트롤 플레인을 제공합니다. SLA는 Autopilot 및 Regional 기준 99.95%입니다.
- AKS: Free Tier를 선택하면 컨트롤 플레인 비용이 완전 무료입니다. 단 SLA가 보장되지 않으므로 개발/테스트용으로만 적합합니다. Standard Tier 적용 시 비용이 발생하며 99.95% SLA를 보장합니다.
4.2. 업그레이드 및 패치 관리 (Lifecycle Management)
- GKE: Release Channel(Rapid, Regular, Stable)이라는 혁신적인 개념을 통해 컨트롤 플레인과 워커 노드의 버전을 Google이 완전 자동으로 롤링 업그레이드합니다. 사용자는 유지보수 창(Maintenance Window)만 설정해두면 됩니다.
- AKS: 자동 업그레이드 채널을 제공하여 패치 및 마이너 버전 업그레이드를 자동화할 수 있습니다. GKE와 유사한 릴리스 트랙 방식을 지원합니다.
- EKS: 가장 보수적인 접근 방식을 취합니다. AWS는 컨트롤 플레인의 마이너 버전 업그레이드를 절대 자동으로 강제하지 않습니다(보안 취약점이나 지원 종료 임박 시점 제외). 운영자가 명시적으로 콘솔이나 CLI에서 업그레이드 버튼을 눌러야만 컨트롤 플레인 업그레이드가 진행되며, 이는 안전성과 통제권을 중시하는 엔터프라이즈 환경에서 환영받는 아키텍처입니다.
4.3. Private Cluster 네트워크 아키텍처
퍼블릭 망을 거치지 않고 내부망에서만 API 서버와 통신하는 프라이빗 아키텍처 구현 방식이 명확히 다릅니다.
- EKS: Private Endpoint 활성화 시, 주입된 ENI를 통해 VPC 내부 라우팅 테이블로 트래픽이 처리됩니다.
- GKE: Private Service Connect (또는 VPC Peering)를 사용하여 내부 IP만으로 컨트롤 플레인에 접근하도록 라우팅합니다.
- AKS: Azure Private Link 서비스를 배포하여 VNet 내부에 Private IP 엔드포인트를 직접 생성하고 컨트롤 플레인과 매핑합니다.
세 클라우드 벤더 모두 "쿠버네티스 컨트롤 플레인을 관리해준다"는 목적은 동일하지만, 내부적으로 격리 수준, 네트워크 연결 방식, 업그레이드 철학에서 확연한 차이를 보입니다. 기업의 보안 요건(강력한 네트워크 격리 필요성), 운영 철학(자동화 vs 수동 제어), 그리고 비용 구조를 종합적으로 고려하여 자사 인프라 철학에 가장 잘 맞는 아키텍처를 선택해야 합니다.
'1. K8s Core & Architecture > 1.1. 컨트롤 플레인 (Control Plane) 심층 분석' 카테고리의 다른 글
| 쿠버네티스 이벤트(Events) 아키텍처: 클러스터 내의 모든 기록 추적하기 (0) | 2026.03.18 |
|---|---|
| etcd 데이터베이스 조각화(Defragmentation) 원리와 유지보수 방법 (0) | 2026.03.18 |
| 컨트롤 플레인 구성 요소의 리소스 할당(CPU/Memory) 최적화 전략 (0) | 2026.03.17 |
| Kube-apiserver 성능 튜닝과 병목 현상 해결 가이드 (0) | 2026.03.17 |
| API 버전 관리(v1, v1beta1 등)와 Deprecation 정책 이해하기 (0) | 2026.03.17 |