“쿠버네티스를 직접 깔 시간은 없으니까” – Azure Kubernetes Service(AKS) 한 번에 이해하기

컨테이너는 익숙한데, 클러스터 관리가 두렵다면 – AKS가 해주는 일과 실제로 쓰는 방식

---

1. AKS가 정확히 뭐 하는 서비스인가

Overview of AKS(이미지 출처 : Micorsoft)

마이크로소프트 공식 문서에 따르면, Azure Kubernetes Service(AKS)는 “컨테이너화된 애플리케이션을 배포·관리·확장할 수 있게 해 주는 관리형 Kubernetes 서비스”입니다. 즉, 쿠버네티스를 직접 설치·운영하는 대신, 컨트롤 플레인(API 서버, etcd, 스케줄러, 컨트롤러 매니저 등)을 Azure가 대신 관리해 주고, 사용자는 워커 노드(실제 애플리케이션이 도는 VM)와 애플리케이션만 집중하면 됩니다. SentinelOne·NetApp 등의 정리 글도 AKS를 “보안·모니터링·오토스케일·롤링 업데이트까지 묶어서 제공하는 컨테이너 오케스트레이션 플랫폼”이라고 설명합니다. 핵심 요약: Docker·컨테이너는 이미 쓰고 있는데, 쿠버네티스 설치·업그레이드·HA 구성·모니터링까지 다 하긴 부담스러울 때, 그 ‘운영 부담’을 Azure 쪽으로 넘기는 서비스라고 보면 됩니다.

참조 : https://learn.microsoft.com/en-us/azure/aks/what-is-aks

2. 아키텍처 – 어떤 부분을 Azure가 대신 맡아 주는가

Azure Learn과 여러 아키텍처 설명을 합치면, AKS 구조는 크게 컨트롤 플레인(완전 관리)과 워커 노드(사용자 구독)로 나뉩니다.

• 컨트롤 플레인 (Azure 관리) - API Server: kubectl·GitOps·파이프라인에서 오는 모든 요청을 처리. - etcd: 클러스터 상태·설정을 저장하는 분산 키-값 저장소. - 스케줄러: 어떤 Pod를 어느 노드에 올릴지 결정. - 컨트롤러 매니저: ReplicaSet, 노드 상태 등 여러 컨트롤러를 관리. → 이 영역은 사용자가 직접 VM을 건드릴 수도 없고, 패치·업그레이드는 Azure가 책임집니다.
• 워커 노드 (사용자 구독의 VM) - Azure VM 위에 kubelet, kube-proxy, containerd 같은 런타임 구성. - 실제 애플리케이션 Pod, coreDNS 등 시스템 Pod가 이쪽에서 실행. - 노드 사이즈·개수·노드 풀(OS·GPU·Spot 여부 등)은 사용자가 결정. → 클러스터 오토스케일러(HPA·CA) 설정에 따라 자동으로 노드·Pod 수를 늘리고 줄일 수 있습니다.

공식 문서는 여기에 아이덴티티·보안·모니터링이 기본 포함된다는 점을 강조합니다. 예를 들어, Microsoft Entra ID(구 Azure AD)와 연동한 RBAC, Azure Policy를 통한 규제 준수, Azure Monitor(Container Insights) 기반 로그·메트릭 수집 같은 부분입니다. 정리하면, “쿠버네티스의 어려운 부분(컨트롤 플레인·보안·모니터링·업그레이드)은 Azure가 대신 들고, 워커 노드와 애플리케이션 설계는 내가 담당”하는 구도입니다.

3. 어떤 상황에서 AKS를 쓰면 좋은가 – 대표 유스케이스

마이크로소프트 공식 문서와 여러 컨설팅·아키텍처 정리에서 공통으로 나오는 AKS 대표 활용 시나리오는 대략 다음과 같습니다.

• 마이크로서비스 운영 - 여러 서비스가 각각 컨테이너로 나뉘어 있을 때, 배포·롤링 업데이트·헬스체크·오토스케일·시크릿 관리 등을 통일된 방식으로 처리. - 예: REST API 여러 개, 백그라운드 워커, 이벤트 소비자 등.
• 레거시 앱 컨테이너화 - 기존 .NET/Java 앱을 큰 리팩토링 없이 컨테이너로 감싸서, 관리형 쿠버네티스 환경에 올리는 용도. - Windows Server 컨테이너도 지원해, 한 클러스터 안에 리눅스·윈도우 혼합 워크로드 가능.
• DevOps/CI·CD 파이프라인 - Azure DevOps·GitHub Actions와 연결해, 브랜치 머지→이미지 빌드·푸시→AKS 배포까지 자동화. - Canary·Blue/Green·롤링 업데이트 전략을 쿠버네티스 레벨에서 구현.
• 배치·머신러닝·데이터 파이프라인 - TensorFlow·Kubeflow 등으로 대규모 학습 작업 수행, GPU 노드 풀 활용. - 수많은 센서·이벤트에서 들어오는 실시간 데이터 스트리밍 처리에도 사용.
• 버스트 워크로드 처리 (ACI 연계) - AKS 클러스터 리소스가 꽉 찼을 때, Azure Container Instances(ACI)와 연동한 가상 노드로 단기적인 부하를 처리. - 서버를 추가로 관리하지 않고도, 몇 초 안에 Pod를 띄워 스파이크 트래픽 대응.

실제 사례로는, 고객-facing 웹서비스를 AKS 위에 올리고, 배경에서 데이터 파이프라인·분석 작업을 같은 클러스터(또는 별도 클러스터)에 두는 패턴이 많이 소개됩니다. 한마디로, “컨테이너는 기본값이고, 여러 서비스·잡을 함께 운영해야 하는 상황”이라면 AKS가 자연스러운 선택지입니다.

4. 실제로 어떻게 쓰기 시작하나 – 아주 간단한 흐름

Azure 공식 가이드와 여러 튜토리얼을 기준으로, AKS를 처음 쓸 때의 기본 흐름은 대략 이렇습니다.

• 1) 컨테이너 이미지 준비
  - 로컬 또는 CI에서 Docker 이미지를 빌드.
  - Azure Container Registry(ACR)에 푸시.
• 2) AKS 클러스터 생성
  - Azure Portal, Azure CLI(az aks create) 또는 ARM/Bicep/Terraform으로 클러스터 생성.
  - 노드 풀 수, VM 사이즈, 네트워크 모드, OS(리눅스/윈도우) 등을 지정.
• 3) kubectl로 연결
  - az aks get-credentials로 kubeconfig를 받아와 로컬 kubectl과 연결.
• 4) 매니페스트 배포
  - Deployment, Service, Ingress, ConfigMap, Secret 등 YAML을 준비해 kubectl apply -f.
  - 필요하면 Helm Chart나 Kustomize 사용.
• 5) 스케일·업그레이드·모니터링
  - HPA(수평 Pod 오토스케일러)·클러스터 오토스케일러를 설정해 자동 스케일링.
  - Azure Monitor(Container Insights)로 메트릭·로그 수집, 경고 설정.
  - az aks upgrade로 Kubernetes 버전·노드 이미지 업그레이드 수행.

Rafay·Meshcloud 같은 서드파티 가이드들은, 여러 팀이 쓸 플랫폼이면 여기에 네임스페이스·권한·비용 태깅까지 자동화해, 개발팀이 직접 AKS 네임스페이스를 셀프서비스로 프로비저닝하는 구조를 추천합니다. 이렇게 세팅해 두면, 이후 개발팀은 “도커 이미지 빌드 → Helm 배포” 수준만 알면 클러스터에 서비스를 올릴 수 있게 됩니다.

5. AKS를 선택할 때 체크할 포인트

공식 문서와 여러 아키텍처 가이드를 정리하면, AKS 도입을 고민할 때 체크해 볼 만한 포인트는 다음과 같습니다.

• 쿠버네티스가 꼭 필요한가? - 단일 서비스·간단한 배치 작업이면 App Service·Container Apps 같은 더 단순한 옵션이 나을 수 있습니다.
• 운영팀의 역량·인력 - 컨트롤 플레인은 Azure가 해 주지만, 네트워크·보안·업그레이드 전략·비용 최적화는 여전히 클라우드·K8s 이해가 필요합니다.
• 기존 Azure 스택과의 통합 - 이미 Entra ID, ACR, Application Gateway, DevOps를 쓰고 있다면 AKS와의 통합 이점이 큽니다.
• 멀티 클러스터/멀티 리전 전략 - 가용성·DR 요구사항에 따라, 여러 리전에 클러스터를 어떻게 나눌지, 트래픽 라우팅을 어떻게 설계할지 미리 그림이 있어야 합니다.

마이크로소프트 문서 표현을 그대로 빌리면, AKS는 “쿠버네티스를 쓰고 싶지만, 컨트롤 플레인 운영까지는 맡고 싶지 않은 팀”을 위한 서비스입니다. 그래서 이걸 도입할지 말지의 기준은, “쿠버네티스 자체를 쓸 거냐 말 거냐”가 아니라, “컨테이너 기반으로 서비스가 이미 흩어져 있고, 그걸 관리하는 표준 레이어가 필요하냐”에 가깝다고 볼 수 있습니다.