컴퓨트

AKS (Azure Kubernetes Service 운영)

AKS 의 구조(관리형 컨트롤 플레인, 노드 풀), Standard 와 2025-09 GA 가 된 AKS Automatic 의 차이, 네트워크 모델(Azure CNI Overlay), Entra 통합과 Workload ID, 버전 지원 정책과 업그레이드, 노드 자동 프로비저닝, 비용 요령을 정리합니다.

AKSAKS AutomaticKubernetes노드 풀Workload ID업그레이드2026-10 기준, 약 7분상태 표시 설명

구조

AKS 는 Kubernetes 컨트롤 플레인(API 서버, etcd, 스케줄러)을 Azure 가 관리하고, 사용자는 노드 풀(VM Scale Sets)만 관리하는 서비스입니다.

시스템 노드 풀: CoreDNS, metrics-server 같은 시스템 파드가 도는 풀. 최소 1개 필요하고, 운영은 3노드 이상, 영역 분산을 권장합니다.
사용자 노드 풀: 앱 파드용. 용도별(일반, 메모리, GPU, Spot)로 나눕니다.
노드 리소스 그룹: MC_ 로 시작하는 리소스 그룹에 VM, 디스크, 부하 분산기가 생깁니다. 여기서 직접 손대면 클러스터가 깨질 수 있습니다.

컨트롤 플레인 계층은 Free, Standard, Premium 이 있습니다. 운영 클러스터는 SLA 가 있는 Standard 이상을 씁니다. Premium 은 장기 지원(LTS)이 필요할 때 고릅니다.

AKS Standard 와 AKS Automatic

AKS Automatic 은 2025-09 에 GA 가 되었습니다. 노드 관리, 확장, 보안 기본값을 Azure 가 맡는 "설정이 끝난 Kubernetes" 입니다.

항목	AKS Standard	AKS Automatic
노드 관리	노드 풀을 직접 설계	Karpenter 기반 노드 자동 프로비저닝
네트워크	선택 (Azure CNI Overlay 권장)	Azure CNI Overlay 기본
노드 OS	선택	Azure Linux 기본
확장	직접 설정	HPA, VPA, KEDA 기본 켜짐
보안	직접 설정	Entra 통합, Azure RBAC, 네트워크 정책, 배포 보호(safeguards) 기본
모니터링	선택	Azure Monitor, Managed Prometheus 기본
유연성	높음	기본값에서 벗어나는 설정은 제한

Kubernetes 전담 팀이 없고 표준적인 웹, API, 배치 워크로드라면 Automatic 으로 시작하는 것이 좋습니다. 특수한 CNI, 노드 커스터마이징, 세밀한 노드 풀 제어가 필요하면 Standard 입니다.

네트워크 모델

모델	파드 IP	특징
Azure CNI Overlay	VNet 과 별도인 오버레이 대역	VNet IP 를 아낌. 대부분의 새 클러스터에 권장
Azure CNI (VNet 직접)	VNet 서브넷 IP	파드가 VNet 에서 바로 보임. IP 를 많이 씀
kubenet	노드 NAT	예전 방식. 새 클러스터에는 쓰지 않음

VNet IP 계획이 빡빡한 기업 네트워크에서는 Overlay 가 거의 정답입니다. 네트워크 정책은 Cilium 기반 데이터 플레인(Azure CNI Powered by Cilium)을 많이 씁니다. 서브넷 크기 계획은 VNet 과 NSG 문서에 있습니다.

az aks create -g rg-shop-prod -n aks-shop-prod --location koreacentral \
  --tier standard --zones 1 2 3 \
  --network-plugin azure --network-plugin-mode overlay --network-dataplane cilium \
  --enable-aad --enable-azure-rbac --enable-oidc-issuer --enable-workload-identity \
  --node-count 3 --node-vm-size Standard_D4s_v5

ID 와 권한

클러스터 접근: Entra 통합 + Azure RBAC for Kubernetes 를 켜면 kubectl 권한을 Azure 역할(Azure Kubernetes Service RBAC Reader, Writer, Admin)로 줍니다. 로컬 계정은 끕니다(--disable-local-accounts).
파드가 Azure 를 부를 때: Microsoft Entra Workload ID 를 씁니다. 사용자 할당 관리 ID 에 페더레이션 자격 증명을 만들고, 서비스 계정에 연결합니다. 예전 파드 관리 ID(pod-managed identity)는 쓰지 않습니다.
이미지 가져오기: ACR 은 az aks update --attach-acr 로 kubelet ID 에 AcrPull 을 줍니다. 이미지 풀 비밀이 필요 없습니다.

버전 지원과 업그레이드

AKS 는 GA 된 Kubernetes 마이너 버전마다 약 12개월 지원하고, 최신 버전(N)과 그 앞 두 버전(N-2)을 지원 창으로 둡니다. 그보다 오래되면 플랫폼 지원으로 내려가고, 유예 기간 뒤 Azure 가 자동으로 올립니다. Premium 계층의 LTS 를 켜면 커뮤니티 지원 종료 뒤 1년을 더 받습니다.

az aks get-versions --location koreacentral -o table
az aks get-upgrades -g rg-shop-prod -n aks-shop-prod -o table

업그레이드 요령입니다.

자동 업그레이드 채널(patch 또는 stable)과 계획된 유지 관리 창을 같이 설정합니다.
노드 OS 이미지 업그레이드 채널(NodeImage 또는 SecurityPatch)은 클러스터 버전과 별개로 둡니다.
PodDisruptionBudget 을 앱마다 둡니다. 너무 엄격한 PDB(maxUnavailable: 0)는 노드 드레인을 영원히 막습니다.
maxSurge 를 늘리면 업그레이드가 빨라지지만 그만큼 vCPU 할당량이 더 필요합니다. 업그레이드 실패의 흔한 원인이 할당량 부족입니다.
사용 중단된 API 는 업그레이드 전에 AKS 진단의 "Kubernetes API deprecations" 로 확인합니다.

확장

방식	대상
HPA	파드 수 (CPU, 메모리, 사용자 지정 메트릭)
KEDA (애드온)	큐 길이, Event Hubs 지연 등 이벤트 기반 파드 수, 0 까지
클러스터 오토스케일러	노드 풀별 노드 수
노드 자동 프로비저닝 (Karpenter)	대기 파드에 맞는 VM 크기를 골라 노드 생성

비용 요령

시스템 풀은 작게, 사용자 풀은 오토스케일러로 늘리고 줄입니다.
중단돼도 되는 워크로드는 Spot 노드 풀에 올리고 tolerations 로 분리합니다.
개발 클러스터는 az aks stop 으로 밤에 멈춥니다. 컨트롤 플레인과 노드 요금이 멈추고 디스크 등은 남습니다.
AKS 비용 분석(cost analysis) 애드온을 켜면 네임스페이스별 비용을 Cost Management 에서 볼 수 있습니다.

언제 AKS 가 아닌가

컨테이너 몇 개를 HTTP 로 돌리고 0 까지 줄이고 싶다면 Container Apps가 운영 부담이 훨씬 적습니다. AKS 는 Kubernetes API 자체가 필요하거나(오퍼레이터, Helm 생태계), 노드 수준 제어가 필요할 때 고릅니다.