AKS(Azure Kubernetes Service)는 API 서버, etcd 같은 Kubernetes 컨트롤 플레인을 Azure가 운영하고, 사용자는 워크로드가 올라가는 노드 풀만 관리하는 관리형 Kubernetes 서비스입니다. 지금 새로 만든다면 네트워크는 Azure CNI Overlay, 사람의 접근은 Microsoft Entra ID와 Azure RBAC, 파드의 Azure 접근은 Workload Identity를 기본으로 잡습니다. 운영에서는 시스템·사용자 노드 풀 분리, 가용성 영역 분산, 자동 업그레이드 채널을 함께 설정합니다.
1. AKS가 필요한 이유
kubeadm(Kubernetes 클러스터 설치 도구)으로 클러스터를 직접 만들면 마스터 노드 이중화, etcd(클러스터 상태 저장소) 백업, 인증서 갱신, 버전 업그레이드, 워커 노드 조인 토큰까지 모두 직접 챙겨야 합니다. 토큰이 만료되면 워커 노드 하나 추가하는 데도 손이 갑니다(토큰 만료 후 워커 노드 추가). AKS는 컨트롤 플레인을 Azure가 운영하므로 사용자는 노드 풀과 워크로드에 집중할 수 있습니다.
| 항목 | kubeadm 직접 구축 | AKS |
| 컨트롤 플레인 | 마스터 VM 직접 구성과 이중화 | Azure가 운영(사용자에게 보이지 않음) |
| etcd 백업·인증서 | 직접 관리 | Azure가 관리 |
| 노드 추가 | 토큰 발급 후 kubeadm join | az aks scale 또는 클러스터 오토스케일러 |
| 버전 업그레이드 | 노드마다 kubeadm upgrade | az aks upgrade, 자동 업그레이드 채널 |
| Azure 연동 | 클라우드 컨트롤러, CSI 드라이버 직접 설치 | Load Balancer, 디스크, Files, Entra ID 기본 연동 |
| 비용 | 마스터와 워커 VM 전부 | 노드 VM + 가격 티어 요금(Free는 관리 요금 없음) |
2. AKS 구성 요소
Control Plane은 Azure가 운영하고, 노드 풀과 네트워크 리소스는 내 구독의 Node Resource Group에 만들어지는 구성
AKS 클러스터를 만들면 리소스 그룹이 두 개 생깁니다. 내가 지정한 리소스 그룹에는 클러스터 리소스 하나만 있고, 실제 VM과 네트워크 리소스는 AKS가 따로 만드는 노드 리소스 그룹(MC_리소스그룹_클러스터_지역)에 들어갑니다.
| 구성 요소 | 위치 | 설명 |
| 컨트롤 플레인 | Azure 관리 영역 | API 서버, etcd, 스케줄러, 컨트롤러. 사용자는 API 서버 엔드포인트만 봅니다. |
| 노드 풀 | 노드 리소스 그룹 | 같은 VM 크기와 OS를 쓰는 노드 묶음입니다. 기본적으로 VMSS(Virtual Machine Scale Sets)로 만들어집니다(VMSS 정리). |
| 노드 리소스 그룹 | 사용자 구독 | VMSS, Load Balancer, 공용 IP, 디스크, 관리 ID가 들어갑니다. AKS가 관리하므로 직접 수정하지 않습니다. |
2.1 시스템 노드 풀과 사용자 노드 풀
| 구분 | 시스템 노드 풀 | 사용자 노드 풀 |
| 역할 | CoreDNS, metrics-server 같은 시스템 파드 | 애플리케이션 파드 |
| 필수 여부 | 클러스터당 최소 1개 | 선택 |
| 최소 노드 수 | 1대 이상(운영은 영역 3개에 3대 권장) | 0대까지 줄일 수 있음 |
| OS | Linux만 가능 | Linux, Windows |
| 권장 설정 | CriticalAddonsOnly=true:NoSchedule 테인트로 앱 파드 차단 | 용도별로 풀 분리(일반, GPU, Spot 등) |
시스템 풀에 앱 파드가 섞이면 앱이 자원을 다 쓸 때 CoreDNS까지 영향을 받습니다. 운영 클러스터에서는 시스템 풀에 테인트를 걸고 앱은 사용자 풀에만 올립니다.
3. AKS Automatic과 AKS Standard
AKS는 두 가지 방식으로 만들 수 있습니다. Standard는 노드 풀, 네트워크, 업그레이드를 모두 직접 고르는 기존 방식이고, Automatic은 Microsoft 권장 구성이 미리 적용되어 노드까지 AKS가 관리하는 방식입니다.
| 항목 | AKS Standard | AKS Automatic |
| 노드 관리 | 노드 풀과 VM 크기를 직접 정함 | 노드 자동 프로비저닝(파드 요청에 맞춰 노드 생성) |
| 네트워크 | CNI(Container Network Interface)와 아웃바운드 방식 직접 선택 | Azure CNI Overlay + Cilium, 관리형 NAT Gateway |
| 업그레이드 | 채널과 유지 관리 기간 직접 설정 | 클러스터와 노드 OS 자동 업그레이드 기본 적용 |
| 보안 | 선택 사항 | Azure RBAC(역할 기반 접근 제어), Workload Identity, 배포 보호 장치, Pod Security Standards 기본 적용 |
| 가격 티어 | Free, Standard, Premium 중 선택 | Standard 티어 |
| 적합한 경우 | 세부 구성이 필요하거나 구조를 익힐 때 | 운영 부담을 줄이고 권장 구성으로 바로 시작할 때 |
이 글은 구성 요소를 하나씩 확인할 수 있도록 Standard를 기준으로 설명합니다. 두 방식의 자세한 비교는 다음 글에서 다룹니다.
4. 가격 티어
| 티어 | 가동 시간 SLA (서비스 수준 계약) |
최대 노드 | LTS(장기 지원) | 쓰는 경우 |
| Free | 없음 | 1,000대 | 없음 | 개발, 테스트, 학습 |
| Standard | 99.95%(영역 사용), 99.9%(영역 미사용) | 5,000대 | 없음 | 운영 클러스터 |
| Premium | Standard와 같음 | 5,000대 | 24개월 | 업그레이드 주기를 길게 가져가야 하는 운영 환경 |
티어는 만든 뒤에도 az aks update --tier로 바꿀 수 있습니다. 노드 VM, 디스크, Load Balancer 비용은 티어와 관계없이 따로 나갑니다.
5. 버전과 업그레이드
AKS는 정식 출시(GA)된 Kubernetes 마이너 버전 3개(N, N-1, N-2)를 지원하고, 마이너 버전 하나의 지원 기간은 약 12개월입니다. 즉 적어도 1년에 한 번은 마이너 업그레이드를 해야 지원 범위 안에 머뭅니다. 작성 시점(2026년 9월)에는 1.34~1.36이 지원되며, 지역별 최신 목록은 az aks get-versions로 확인합니다.
| 설정 | 값 | 동작 |
| 클러스터 자동 업그레이드 (--auto-upgrade-channel) |
none | 자동 업그레이드 안 함 |
| patch | 현재 마이너 버전의 최신 패치로 올림(운영 권장) | |
| stable | 최신 마이너보다 하나 낮은 버전(N-1)의 최신 패치로 올림 | |
| rapid | 최신 마이너 버전의 최신 패치로 올림 | |
| 노드 OS 업그레이드 (--node-os-upgrade-channel) |
NodeImage | 보안 패치가 반영된 새 노드 이미지로 교체 |
| SecurityPatch | 노드를 교체하지 않고 보안 패치만 적용 | |
| None / Unmanaged | 자동 적용 안 함 / OS 자체 업데이트에 맡김 |
업그레이드는 임시 노드를 먼저 추가(surge)하고, 기존 노드를 cordon(새 파드 배치 중지)·drain(기존 파드 이동)한 뒤 삭제하는 방식으로 진행됩니다. --max-surge를 늘리면 빨라지지만 그만큼 서브넷 IP와 vCPU 할당량이 더 필요합니다. 자동 업그레이드를 켤 때는 유지 관리 기간(az aks maintenanceconfiguration)을 함께 설정해 업무 시간을 피합니다.
6. 네트워킹
6.1 네트워크 플러그인(CNI)
파드가 IP를 어디서 받는지가 CNI 선택의 핵심입니다. 최신 Azure CLI는 옵션 없이 만들면 Azure CNI Overlay가 기본값입니다.
CNI 방식별로 노드와 파드가 IP를 받는 위치를 비교한 구성
| 방식 | 파드 IP | 특징 | 비고 |
| kubenet | 노드와 다른 대역, NAT | 라우팅 테이블 사용, 노드 400대 제한 | 2028년 3월 31일 지원 종료 |
| Azure CNI(평면) | VNet 서브넷에서 직접 받음 | 온프레미스에서 파드 IP로 직접 통신 가능 | IP를 많이 사용해 서브넷 설계가 중요 |
| Azure CNI Overlay | 별도 CIDR(기본 10.244.0.0/16) | VNet IP는 노드만 사용, 대규모 확장에 유리 | CLI 기본값, 대부분의 경우 권장 |
| Azure CNI Powered by Cilium | Overlay 또는 평면과 조합 | eBPF(커널에서 동작하는 네트워크 처리) 데이터플레인, kube-proxy 없음, 네트워크 정책 성능 향상 | --network-dataplane cilium |
Overlay에서 파드가 클러스터 밖으로 나갈 때는 노드 IP로 SNAT(출발지 주소 변환)됩니다. 그래서 온프레미스에서 파드 IP로 직접 접근할 수는 없고, 서비스(내부 Load Balancer)나 인그레스로 노출해야 합니다. kubenet을 쓰고 있다면 az aks update --network-plugin azure --network-plugin-mode overlay로 옮겨 둡니다.
6.2 아웃바운드
| --outbound-type | 동작 | 쓰는 경우 |
| loadBalancer(기본) | AKS가 만든 Standard Load Balancer의 아웃바운드 규칙과 공용 IP로 나감 | 간단한 구성 |
| managedNATGateway userAssignedNATGateway |
NAT Gateway로 나감 | 외부 호출이 많아 SNAT 포트가 부족할 때 |
| userDefinedRouting | 서브넷의 UDR(사용자 정의 경로)을 따라 Azure Firewall이나 NVA(네트워크 가상 어플라이언스)로 나감 | Hub-Spoke에서 방화벽을 거쳐야 할 때 |
Hub의 방화벽으로 아웃바운드를 보내는 구성은 Hub-Spoke 네트워크 구성, Azure Firewall, NSG, WAF 역할 정리와 이어집니다. 이때 AKS가 필요로 하는 도메인(FQDN: MCR, 관리 엔드포인트 등)을 방화벽에서 허용해야 노드가 정상적으로 올라옵니다.
6.3 API 서버 접근
| 방식 | 설명 |
| 공용 API 서버 + 허용 IP | 공용 엔드포인트를 두고 --api-server-authorized-ip-ranges로 접근 IP를 제한합니다. |
| 프라이빗 클러스터 | API 서버를 Private Endpoint로 노출하고 privatelink.<지역>.azmk8s.io Private DNS Zone으로 이름을 해석합니다. 온프레미스에서 접근하려면 DNS Private Resolver가 필요합니다(Private DNS Zone과 DNS Private Resolver 정리). |
| API 서버 VNet 통합 | API 서버를 위임된 서브넷에 직접 넣어 노드와 API 서버 사이 통신을 VNet 안에서 처리합니다. |
6.4 서비스 노출
type: LoadBalancer 서비스를 만들면 AKS가 Azure Load Balancer에 규칙과 공용 IP를 자동으로 추가합니다(Azure Load Balancer 정리). 내부 IP로만 노출하려면 서비스에 service.beta.kubernetes.io/azure-load-balancer-internal: "true" 어노테이션을 붙입니다.
HTTP 라우팅이 필요하면 인그레스나 Gateway API를 씁니다. 업스트림 ingress-nginx 프로젝트는 2026년 3월 유지보수가 끝났고, AKS 애플리케이션 라우팅 추가 기능의 관리형 NGINX도 2026년 11월까지 중요 보안 패치만 지원됩니다. 새로 구성한다면 Gateway API 기반(애플리케이션 라우팅의 Istio 기반 Gateway API, Application Gateway for Containers)으로 시작하는 것이 좋습니다. 인그레스 선택은 다음 글에서 자세히 다룹니다.
7. 인증과 권한
| 대상 | 방식 | 설명 |
| 사람 → 클러스터 | Microsoft Entra ID + Azure RBAC | Azure 역할(Azure Kubernetes Service RBAC Reader, Writer, Admin, Cluster Admin)로 kubectl 권한을 줍니다. 공유 관리자 인증서를 막으려면 --disable-local-accounts로 로컬 계정을 끕니다. |
| 클러스터 → Azure | 관리 ID | 클러스터 ID는 Load Balancer, 서브넷 같은 리소스를 관리하고, kubelet ID는 ACR에서 이미지를 가져옵니다. |
| 파드 → Azure | Workload Identity | Kubernetes 서비스 계정과 사용자 할당 관리 ID를 페더레이션으로 연결합니다. 비밀 없이 Key Vault, Storage에 접근할 수 있습니다. |
8. Azure CLI로 만들어 보기
실습 비용을 줄이기 위해 Free 티어로 만듭니다. 운영 클러스터라면 --tier standard로 바꿉니다.
8.1 클러스터 만들기
RG=rg-aks
LOC=koreacentral
AKS=aks-demo
az group create --name $RG --location $LOC
# 지역에서 쓸 수 있는 Kubernetes 버전 확인
az aks get-versions --location $LOC --output table
# 시스템 노드 풀 3대(영역 1·2·3), Overlay + Cilium, Entra ID + Azure RBAC
az aks create --resource-group $RG --name $AKS \
--tier free \
--network-plugin azure --network-plugin-mode overlay \
--network-dataplane cilium --pod-cidr 10.244.0.0/16 \
--nodepool-name system --node-count 3 --zones 1 2 3 \
--node-vm-size Standard_D2s_v5 \
--nodepool-taints CriticalAddonsOnly=true:NoSchedule \
--enable-aad --enable-azure-rbac --disable-local-accounts \
--enable-oidc-issuer --enable-workload-identity \
--auto-upgrade-channel patch --node-os-upgrade-channel NodeImage \
--generate-ssh-keys8.2 사용자 노드 풀
# 앱을 올릴 풀: 2~5대 사이에서 자동 조정
az aks nodepool add --resource-group $RG --cluster-name $AKS --name apps \
--mode User --node-vm-size Standard_D2s_v5 --zones 1 2 3 \
--node-count 2 --enable-cluster-autoscaler --min-count 2 --max-count 5 \
--max-surge 33%8.3 권한 부여와 접속
Azure RBAC를 켜면 클러스터를 만든 계정이라도 Kubernetes 권한이 자동으로 생기지 않습니다. 내 계정에 역할을 먼저 할당합니다. 역할이 반영되기까지 몇 분 걸릴 수 있습니다.
ME=$(az ad signed-in-user show --query id --output tsv)
AKS_ID=$(az aks show --resource-group $RG --name $AKS --query id --output tsv)
az role assignment create --assignee $ME \
--role "Azure Kubernetes Service RBAC Cluster Admin" --scope $AKS_ID
# kubectl, kubelogin 설치 후 kubeconfig 받기
az aks install-cli
az aks get-credentials --resource-group $RG --name $AKS
kubelogin convert-kubeconfig -l azurecli
kubectl get nodes -o wide8.4 앱 배포와 노출
kubectl create deployment web --image=nginx --replicas=3
kubectl expose deployment web --port=80 --type=LoadBalancer
# EXTERNAL-IP가 할당되면 접속
kubectl get svc web -w
# 시스템 풀에는 테인트가 있으므로 파드는 apps 풀에만 배치됨
kubectl get pods -o wide노드 리소스 그룹에 어떤 리소스가 만들어졌는지도 확인해 봅니다. 서비스를 만들면서 Load Balancer에 규칙과 공용 IP가 추가된 것을 볼 수 있습니다.
NRG=$(az aks show --resource-group $RG --name $AKS \
--query nodeResourceGroup --output tsv)
az resource list --resource-group $NRG --output table
# 실습이 끝나면 삭제(노드 리소스 그룹도 함께 삭제됨)
az group delete --name $RG --yes --no-wait9. 운영 시 주의점
| 증상·항목 | 확인할 것 |
| 파드가 Pending에 머묾 | 파드의 requests가 노드 크기보다 크지 않은지, 테인트와 톨러레이션, 오토스케일러 최대 대수를 확인합니다. 오토스케일러는 사용량이 아니라 requests를 기준으로 노드를 늘립니다. |
| 업그레이드가 진행되지 않음 | kubectl get pdb에서 ALLOWED DISRUPTIONS가 0인 PDB(PodDisruptionBudget, 동시에 중단할 수 있는 파드 수 제한)가 drain을 막고 있지 않은지 확인합니다. surge 노드용 서브넷 IP와 vCPU 할당량도 확인합니다. |
| 서브넷 IP 부족 | 평면 Azure CNI는 노드마다 최대 파드 수만큼 IP를 씁니다. 새 클러스터는 Overlay를 쓰고, 업그레이드 surge와 확장 여유분까지 고려해 서브넷을 잡습니다. |
| MC_ 리소스 그룹 수정 | VMSS, Load Balancer를 직접 바꾸면 업그레이드나 확장이 실패할 수 있습니다. 변경은 항상 AKS API(az aks, 매니페스트)로 합니다. |
| 시스템 풀에 앱 파드 | 시스템 풀에 CriticalAddonsOnly 테인트를 걸고 앱은 사용자 풀로 분리합니다. |
| 외부 호출 실패, 간헐적 연결 오류 | Load Balancer 아웃바운드의 SNAT 포트가 부족한지 확인하고, 필요하면 NAT Gateway로 바꿉니다. |
| 버전 지원 종료 | 마이너 버전 지원은 약 12개월입니다. 자동 업그레이드 채널과 유지 관리 기간을 설정해 둡니다. |
| 관리형 NGINX 인그레스 | 2026년 11월 이후 지원이 끝나므로 Gateway API 기반으로 이전 계획을 세웁니다. |
| kubenet 사용 중 | 2028년 3월 31일 전에 Azure CNI Overlay로 전환합니다. |
10. 정리
- AKS는 컨트롤 플레인을 Azure가 운영하고, 사용자는 VMSS 기반 노드 풀과 워크로드를 관리합니다. 실제 리소스는 MC_ 노드 리소스 그룹에 만들어집니다.
- 새 클러스터는 Azure CNI Overlay, Entra ID + Azure RBAC, Workload Identity를 기본으로 하고, 시스템 풀과 사용자 풀을 나눠 영역에 분산합니다.
- 마이너 버전은 약 1년마다 올려야 하므로 자동 업그레이드 채널과 유지 관리 기간을 설정하고, 관리형 NGINX 인그레스는 Gateway API로 이전을 준비합니다.
다음 글에서는 AKS 네트워킹(CNI와 아웃바운드), 인그레스와 Gateway API, 인증과 Workload Identity, AKS Automatic을 하나씩 자세히 정리합니다.
참고
'Cloud > Azure' 카테고리의 다른 글
| [Azure] Private DNS Zone과 DNS Private Resolver 정리 (0) | 2026.09.25 |
|---|---|
| [Azure] Virtual Machine Scale Sets 정리 (0) | 2026.09.25 |
| [Azure] Azure 부하 분산 서비스 비교 (0) | 2026.09.25 |
| [Azure] Front Door와 Application Gateway 연동 정리 (0) | 2026.09.25 |
| [Azure] Azure WAF 정책과 규칙 정리 (0) | 2026.09.25 |
