Azure AKS 기본 구조: Control Plane, Node Pool, Networking

"Azure에서 Kubernetes를 쓰기로 했는데, EKS랑 뭐가 다르죠?" AKS는 Control Plane을 Azure가 무료로 관리해주는 매니지드 Kubernetes 서비스입니다. 다만 Node Pool 구성과 네트워킹 모델에 따라 비용, 보안, 확장성이 크게 달라집니다. 이 글에서는 AKS 클러스터를 처음 설계할 때 반드시 이해해야 하는 세 가지 축(Control Plane, Node Pool, Networking)을 정리합니다.

핵심 요약

• AKS Control Plane은 Azure가 완전 관리합니다. Free 티어에서는 비용이 발생하지 않지만 SLA가 없습니다. Standard 티어($0.10/시간)부터 99.95% SLA가 보장됩니다.
• Node Pool은 System Pool(클러스터 운영 컴포넌트)과 User Pool(애플리케이션 워크로드)로 분리하는 것이 운영 안정성 측면에서 권장됩니다.
• 네트워킹은 Azure CNI Overlay가 현재 권장 모델입니다. kubenet은 2028년 3월 지원 종료 예정이므로 신규 클러스터에서는 사용하지 않는 것이 좋습니다.
• AKS 클러스터는 반드시 VNet 내부에 배치됩니다. 기존 VNet에 통합할지, 새 VNet을 생성할지는 네트워크 설계 초기에 결정해야 합니다.

1. AKS란 무엇인가

AKS(Azure Kubernetes Service)는 Azure에서 제공하는 매니지드 Kubernetes 서비스입니다. Control Plane(API Server, etcd, Scheduler, Controller Manager)을 Azure가 관리하고, 사용자는 Worker Node에서 애플리케이션을 실행하는 데 집중합니다.

스타트업에서 마이크로서비스 10개를 운영한다고 가정합니다. VM에 직접 Kubernetes를 설치하면 etcd 백업, API Server 인증서 갱신, Control Plane 업그레이드를 모두 직접 해야 합니다. AKS를 사용하면 이 운영 부담이 사라지고, Node Pool과 네트워킹 설계에만 집중할 수 있습니다.

구분	자체 운영 (kubeadm 등)	AKS
Control Plane 관리	직접 설치, 업그레이드, 모니터링	Azure가 완전 관리
etcd 백업	직접 구성	Azure가 자동 백업
업그레이드	수동 (다운타임 관리 필요)	포털/CLI에서 한 번의 명령으로 가능
인증서 관리	수동 갱신	자동 갱신
비용	VM + 운영 인력	Node VM 비용 + 선택적 관리 비용
SLA	직접 설계	Free(SLA 없음) / Standard(99.95%) / Premium(99.99%)

2. AKS 전체 아키텍처 구조

AKS 전체 아키텍처

AKS 클러스터는 크게 세 영역으로 나뉩니다.

영역	관리 주체	핵심 구성 요소
Control Plane	Azure (사용자 접근 불가)	API Server, etcd, Scheduler, Controller Manager
Node Pool	사용자 (Azure가 VM 프로비저닝)	System Pool, User Pool, Virtual Nodes
Networking	사용자 설계 + Azure 인프라	VNet, Subnet, CNI, Load Balancer, DNS

핵심 설계 포인트: Control Plane은 Azure가 관리하는 별도 인프라에서 동작하며, 사용자의 Subscription에는 노출되지 않습니다. 사용자는 API Server 엔드포인트를 통해서만 Control Plane과 통신합니다. 이 구조 덕분에 사용자가 실수로 Control Plane을 손상시킬 가능성이 없습니다.

3. Control Plane: Azure가 관리하는 영역

AKS Control Plane 구조

3.1 Control Plane 구성 요소

AKS Control Plane은 표준 Kubernetes Control Plane과 동일한 컴포넌트로 구성됩니다.

컴포넌트	역할
API Server	모든 클러스터 조작의 진입점. kubectl, Azure Portal, CI/CD 모두 API Server를 통해 통신
etcd	클러스터 상태를 저장하는 분산 키-값 저장소
Scheduler	Pod를 어느 Node에 배치할지 결정
Controller Manager	Desired State와 현재 상태를 비교하고 자동 조정
Cloud Controller Manager	Azure 리소스(Load Balancer, Disk 등)와 Kubernetes를 연결

3.2 사용자가 제어할 수 있는 범위

Control Plane은 Azure가 관리하지만, 사용자가 설정할 수 있는 항목도 있습니다.

설정 가능	설정 불가
Kubernetes 버전 선택	etcd 직접 접근
API Server의 네트워크 접근 제한 (Authorized IP Ranges)	Control Plane VM 스펙 변경
Private Cluster 설정 (API Server를 VNet 내부로 제한)	Control Plane 로그의 실시간 접근
업그레이드 채널 설정 (None, Patch, Stable, Rapid, Node Image)	API Server 인증서 직접 관리
Azure AD 통합 (RBAC)	Scheduler 알고리즘 커스터마이징

3.3 Pricing Tier와 SLA

AKS Control Plane 비용은 Pricing Tier에 따라 결정됩니다.

티어	비용	SLA	최대 노드 수	주요 대상
Free	무료	없음	1,000	개발/테스트, 실험
Standard	$0.10/시간 (~$73/월)	99.95% (AZ 사용 시)	5,000	프로덕션 워크로드
Premium	$0.60/시간 (~$438/월)	99.99% (AZ 사용 시)	5,000	미션 크리티컬 워크로드, LTS 지원

운영 환경에서의 판단 기준:

• 개발/스테이징 환경: Free 티어로 충분합니다. SLA가 없어도 업무에 영향이 크지 않습니다.
• 일반 프로덕션: Standard 티어를 사용합니다. 월 $73로 99.95% SLA를 확보할 수 있습니다.
• 금융/의료 등 규제 환경: Premium 티어를 검토합니다. LTS(Long-Term Support) 버전을 사용할 수 있어 업그레이드 주기를 늘릴 수 있습니다.

# AKS 클러스터 생성 시 Standard 티어 지정
az aks create \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --tier standard \
  --kubernetes-version 1.30 \
  --location koreacentral

3.4 Private Cluster vs Public Cluster

API Server 접근 방식은 보안 설계의 핵심입니다.

구분	Public Cluster	Private Cluster
API Server 접근	인터넷에서 접근 가능	VNet 내부에서만 접근 가능
보안 수준	Authorized IP Ranges로 제한 가능	네트워크 레벨에서 완전 격리
운영 복잡도	낮음	높음 (Bastion/VPN 필요)
CI/CD 연결	외부 CI/CD에서 직접 접근 가능	Private Endpoint 또는 Run Command 필요
적합한 환경	개발/테스트, 빠른 프로토타이핑	프로덕션, 규제 환경

Tip
프로덕션 환경에서 Public Cluster를 사용하더라도 반드시 Authorized IP Ranges를 설정해야 합니다. API Server가 무방비로 인터넷에 노출되면 무차별 인증 시도(brute-force)의 대상이 됩니다.

4. Node Pool: 워크로드를 실행하는 영역

AKS Node Pool 구조

4.1 Node Pool이란

Node Pool은 동일한 VM 크기(SKU)와 설정을 공유하는 노드들의 그룹입니다. AKS에서는 최소 1개의 System Node Pool이 필요하며, 워크로드 특성에 따라 여러 User Node Pool을 추가할 수 있습니다.

4.2 System Pool vs User Pool

구분	System Pool	User Pool
목적	클러스터 운영 컴포넌트 (CoreDNS, metrics-server 등)	애플리케이션 워크로드
필수 여부	최소 1개 필수	선택 (0개 가능)
최소 노드 수	프로덕션에서 3개 이상 권장	워크로드에 따라 결정
Taint	CriticalAddonsOnly=true:NoSchedule 설정 가능	워크로드 요구에 따라 자유롭게
VM 크기 권장	Standard_D4s_v5 이상	워크로드 특성에 맞춤
스케일링	보수적 (안정성 우선)	적극적 (비용 최적화 가능)

System Pool과 User Pool을 분리하는 이유: 애플리케이션 Pod가 리소스를 과도하게 사용해서 CoreDNS나 kube-proxy 같은 시스템 컴포넌트가 리소스 부족으로 죽으면 클러스터 전체가 불안정해집니다. Pool을 분리하면 이 위험을 줄일 수 있습니다.

4.3 실무 Node Pool 설계 예시

웹 서비스를 운영하는 팀이 다음과 같은 요구사항을 가진다고 가정합니다: - API 서버: 안정적인 CPU 성능 필요 - 배치 처리: 야간에 대량 데이터 처리, 낮에는 불필요 - ML 추론: GPU 필요

# System Pool (클러스터 운영용)
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name systempool \
  --mode System \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --zones 1 2 3

# User Pool - API 워크로드
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name apipool \
  --mode User \
  --node-count 3 \
  --node-vm-size Standard_D4s_v5 \
  --zones 1 2 3 \
  --enable-cluster-autoscaler \
  --min-count 3 \
  --max-count 10

# User Pool - 배치 처리 (Spot VM으로 비용 절감)
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name batchpool \
  --mode User \
  --node-count 0 \
  --node-vm-size Standard_D8s_v5 \
  --priority Spot \
  --spot-max-price -1 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 20

# User Pool - GPU 워크로드
az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name gpupool \
  --mode User \
  --node-count 1 \
  --node-vm-size Standard_NC6s_v3 \
  --node-taints "nvidia.com/gpu=true:NoSchedule"

4.4 Node Pool 설계 시 고려사항

관점	고려 사항
가용성	Availability Zone 분산 배치 (zones 1 2 3)
비용	Spot VM 활용, Autoscaler min-count 0으로 유휴 비용 제거
격리	Taint/Toleration으로 워크로드 격리
업그레이드	Node Pool별 독립 업그레이드 가능 (Blue-Green 전략 적용 가능)
OS	Ubuntu 22.04(기본), Azure Linux, Windows Server 선택 가능

주의
System Pool의 노드 수를 1개로 운영하면, 해당 노드 유지보수(업그레이드, 패치) 시 CoreDNS가 중단되어 클러스터 내 DNS 해석이 불가능해질 수 있습니다. 프로덕션에서는 최소 3개 노드를 권장합니다.

5. Networking: Pod가 통신하는 방식

AKS 네트워킹 모델 비교

AKS에서 네트워킹 모델 선택은 IP 주소 관리, 성능, Azure 서비스 통합에 직접적으로 영향을 미칩니다.

5.1 네트워킹 모델 종류

모델	Pod IP 할당 방식	VNet 통합	상태
Azure CNI Overlay	별도 오버레이 네트워크에서 할당	Node만 VNet IP 사용	권장 (현재 기본값)
Azure CNI (Node Subnet)	VNet Subnet에서 직접 할당	Pod가 VNet IP 직접 사용	레거시 (지원 유지)
Azure CNI (Pod Subnet)	별도 Subnet에서 Pod에 할당	Pod가 VNet IP 사용	레거시 (지원 유지)
kubenet	노드 내부 Bridge 네트워크	UDR 기반 라우팅	2028년 3월 종료 예정

5.2 Azure CNI Overlay (권장)

Azure CNI Overlay는 현재 AKS에서 권장하는 네트워킹 모델입니다.

동작 방식: 1. Node는 VNet Subnet에서 IP를 할당받습니다. 2. Pod는 별도의 오버레이 네트워크(기본 10.244.0.0/16)에서 IP를 할당받습니다. 3. 같은 Node 내 Pod 간 통신은 로컬에서 처리됩니다. 4. 다른 Node의 Pod와 통신 시, 오버레이 네트워크가 패킷을 캡슐화하여 전달합니다.

장점: - IP 효율성: Pod IP가 VNet 주소 공간을 소비하지 않으므로, 작은 Subnet으로도 대규모 클러스터 운영이 가능합니다. - 확장성: Node당 250개 Pod까지 지원합니다. - 단순한 IP 계획: VNet 설계 시 Pod 수까지 고려하지 않아도 됩니다.

제약: - Pod IP가 VNet IP가 아니므로, VNet 내 다른 리소스에서 Pod IP로 직접 라우팅이 불가능합니다. - Azure Network Policy는 지원되지만, 일부 Azure 서비스(예: Application Gateway 직접 연결)에서 제약이 있을 수 있습니다.

5.3 Azure CNI (Node Subnet) — 레거시

이 모델에서는 모든 Pod가 VNet Subnet에서 직접 IP를 할당받습니다.

장점: - Pod가 VNet의 일급 시민(first-class citizen)으로 동작합니다. 다른 Azure 리소스에서 Pod IP로 직접 접근 가능합니다. - Network Policy, Service Endpoint, Private Endpoint와의 호환성이 높습니다.

단점: - IP 소모가 큼: Node당 최대 250개 Pod × Node 수만큼의 IP를 Subnet에 미리 확보해야 합니다. - 대규모 Subnet 필요: 30 Node × 30 Pod = 900 IP. 실제로는 여유분까지 고려하면 /22 이상의 Subnet이 필요합니다. - VNet Address Space가 부족하면 클러스터 확장이 불가능합니다.

5.4 kubenet — 지원 종료 예정

kubenet은 AKS 초기부터 사용된 단순한 네트워킹 모델입니다. 2028년 3월 31일에 지원이 종료됩니다. 기존 클러스터는 Azure CNI Overlay로 마이그레이션해야 합니다.

5.5 네트워킹 모델 선택 기준

AKS 네트워킹 선택 가이드

상황	권장 모델	이유
신규 클러스터 (일반 목적)	Azure CNI Overlay	IP 효율적, 확장 용이, Microsoft 권장
Pod에서 Azure 서비스 직접 통신 필요	Azure CNI (Node Subnet)	Pod IP가 VNet IP이므로 Service Endpoint 등 활용 가능
기존 kubenet 클러스터	Azure CNI Overlay로 마이그레이션	2028년 종료 대비
IP 주소 공간이 극도로 제한된 환경	Azure CNI Overlay	VNet IP를 Node만 사용하므로 효율적

5.6 VNet과 Subnet 설계

AKS 클러스터의 Subnet 설계는 네트워킹 모델에 따라 달라집니다.

Azure CNI Overlay 사용 시 Subnet 계획:

항목	크기 산정 기준
AKS Node Subnet	Node 수 + 업그레이드 여유분 (예: 30 Node면 /26 이상)
Internal Load Balancer Subnet	별도 Subnet 권장 (작은 /28이면 충분)
Azure Application Gateway Subnet	/24 권장 (AppGW v2 요구사항)

# VNet과 Subnet 생성 예시
az network vnet create \
  --resource-group myResourceGroup \
  --name aks-vnet \
  --address-prefix 10.0.0.0/16 \
  --location koreacentral

# AKS Node Subnet
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name aks-vnet \
  --name aks-nodes \
  --address-prefixes 10.0.1.0/24

# Internal LB Subnet
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name aks-vnet \
  --name internal-lb \
  --address-prefixes 10.0.2.0/28

# Application Gateway Subnet (필요 시)
az network vnet subnet create \
  --resource-group myResourceGroup \
  --vnet-name aks-vnet \
  --name appgw-subnet \
  --address-prefixes 10.0.3.0/24

5.7 Ingress와 외부 트래픽 흐름

외부 트래픽이 AKS 내 Pod에 도달하는 일반적인 경로:

1. 사용자 요청 → Azure Load Balancer (L4) 또는 Application Gateway (L7)
2. LB/AppGW → Node의 kube-proxy가 Service로 라우팅
3. Service → 해당 Pod로 트래픽 전달

Ingress Controller 선택지: - NGINX Ingress Controller: 가장 보편적, 커뮤니티 지원 풍부 - Application Gateway Ingress Controller (AGIC): Azure 네이티브, WAF 통합 - Istio/Envoy 기반: Service Mesh가 필요한 경우

6. 세 가지 축의 연결: 전체 흐름

AKS 전체 트래픽 흐름

사용자의 HTTP 요청이 AKS Pod에 도달하기까지의 전체 흐름을 정리합니다.

1. 사용자가 도메인으로 요청 → Azure DNS가 IP 반환
2. 요청이 Azure Load Balancer 또는 Application Gateway에 도달
3. LB가 AKS Node의 NodePort로 전달
4. kube-proxy가 Service 규칙에 따라 적절한 Pod로 라우팅
5. Pod가 응답을 반환 (역경로로 전달)

이 과정에서 Control Plane은 "어떤 Pod가 어떤 Node에서 실행 중인지" 상태를 관리하고, 네트워킹 레이어는 "트래픽을 올바른 Pod로 전달하는 경로"를 제공합니다.

7. 비용 관점 정리

비용 항목	설명
Control Plane	Free 티어: 무료 / Standard: ~$73/월 / Premium: ~$438/월
Node VM	선택한 VM SKU × Node 수 × 시간 (가장 큰 비용)
Load Balancer	Standard LB 규칙당 과금 + 데이터 처리량
Egress 트래픽	Azure 외부로 나가는 트래픽에 과금
Disk	Node OS Disk + PVC(Persistent Volume)
IP 주소	Public IP 사용 시 개당 과금

비용 최적화 전략: - Spot VM Node Pool: 중단 가능한 워크로드(배치, CI/CD)에 활용하면 최대 90% 절감 가능 - Autoscaler 활용: min-count 0으로 설정하면 유휴 시간에 노드 비용 제거 - Azure Reservations: 1년/3년 예약 시 VM 비용 최대 72% 절감 - Free 티어 활용: 비프로덕션 환경은 Free 티어로 Control Plane 비용 제거

8. 운영 시 주의사항

업그레이드 전략

AKS는 Control Plane과 Node Pool을 독립적으로 업그레이드할 수 있습니다.

# Control Plane 버전 확인
az aks show --resource-group myResourceGroup --name myAKSCluster \
  --query "kubernetesVersion"

# 사용 가능한 업그레이드 버전 확인
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

# Control Plane만 먼저 업그레이드
az aks upgrade --resource-group myResourceGroup --name myAKSCluster \
  --kubernetes-version 1.31 --control-plane-only

# Node Pool 업그레이드 (Surge 설정으로 다운타임 최소화)
az aks nodepool upgrade \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name apipool \
  --kubernetes-version 1.31 \
  --max-surge 33%

업그레이드 순서: Control Plane 먼저, Node Pool 나중에. Control Plane은 Node Pool보다 최대 2 마이너 버전 높을 수 있지만, Node Pool이 Control Plane보다 높을 수는 없습니다.

모니터링과 진단

도구	용도
Azure Monitor (Container Insights)	Node/Pod 메트릭, 로그 수집
Azure Diagnostics	Control Plane 로그 (API Server audit, scheduler)
Prometheus + Grafana	커스텀 메트릭, 세밀한 대시보드
Azure Advisor	비용/보안/성능 권장사항

9. EKS와의 주요 차이점

AWS EKS 경험이 있는 엔지니어를 위해 핵심 차이를 정리합니다.

기준	AKS	EKS
Control Plane 비용	Free 티어 있음 (SLA 없음)	항상 $0.10/시간
기본 CNI	Azure CNI Overlay	VPC CNI (Pod에 VPC IP 할당)
노드 그룹	Node Pool (System/User 구분)	Managed Node Group / Fargate
Ingress	NGINX / AGIC (Application Gateway)	ALB Controller
서비스 메시	Istio 기반 Add-on (Preview)	App Mesh 또는 직접 구성
IAM 통합	Azure AD + Workload Identity	IAM Roles for Service Accounts (IRSA)
자동 업그레이드	채널 기반 자동 업그레이드 지원	수동 (자동 업그레이드는 제한적)

정리

AKS 클러스터를 설계할 때 결정해야 하는 핵심 항목을 요약합니다.

결정 사항	선택지	판단 기준
Pricing Tier	Free / Standard / Premium	SLA 요구 수준, 예산
API Server 접근	Public / Private	보안 요구 수준, 운영 복잡도 허용 범위
Node Pool 분리	System + User	프로덕션이면 분리 권장
네트워킹 모델	Azure CNI Overlay / Azure CNI	IP 효율성 vs Azure 서비스 직접 통합 필요성
Node VM 타입	General Purpose / Spot / GPU	워크로드 특성, 비용
업그레이드 방식	수동 / 자동 (채널 선택)	운영 팀 역량, 변경 관리 정책

다음 글에서는 AKS 클러스터에서 워크로드를 배포할 때 사용하는 Deployment, Service, Ingress 설정과 실무 패턴을 다룹니다.

---

참고 자료 - Azure AKS Documentation - Concepts - AKS Networking Concepts - AKS Pricing Tiers - AKS Node Pools