Docker로 이미지를 만들었고, Kubernetes로 오케스트레이션하는 법도 배웠다.
근데 이 쿠버네티스를 클라우드 환경에서
혼자서 잘 운영하기에는 쉽지않다.
이번 주에는 Azure의 컨테이너 서비스 생태계와 컨테이너 기반 앱 배포 방법을 알아본다.
1. 클라우드 기반의 쿠버네티스의 이해
AKS (Azure Kubernetes Service)
AKS는 Azure에서 제공하는 Managed Kubernetes 서비스다. AWS의 EKS, GCP의 GKE에 대응하는 서비스로, Control Plane을 Azure가 관리해준다는 것이 핵심이다.
셀프 호스팅 K8s와 AKS의 차이를 정리하면:
| 항목 | 셀프 호스팅 K8s | AKS (Managed) |
|---|---|---|
| Control Plane 관리 | 직접 (etcd, API Server, Scheduler 등) | Azure가 관리 (무료) |
| Worker Node 관리 | 직접 | Node Pool 단위로 Azure가 프로비저닝 |
| K8s 버전 업그레이드 | 수동 (다운타임 리스크) | Azure Portal / CLI에서 클릭 한 번 |
| 네트워크 설정 | CNI 직접 선택·설치 | Azure CNI 또는 kubenet 선택 |
| 모니터링 | Prometheus/Grafana 직접 구축 | Azure Monitor / Container Insights 통합 |
| 비용 | 전체 인프라 비용 + 운영 인력 | Control Plane 무료, Worker Node VM 비용만 |
AKS의 아키텍처를 보면, 사용자가 YAML manifest를 K8s API endpoint에 제출하면, Azure managed Control Plane이 이를 받아서 Worker Node(Customer VM)에 Pod을 스케줄링한다. 사용자는 Worker Node의 스펙(VM 사이즈, 노드 수)만 결정하면 된다.
AKS의 Virtual Nodes
AKS에는 Virtual Nodes라는 독특한 기능이 있다. 일반 Node Pool의 VM 위에서 Pod을 실행하는 것이 기본이지만, Virtual Nodes를 활성화하면 Azure Container Instances(ACI) 위에서 Pod을 실행할 수 있다.
이게 왜 유용한가? 트래픽 버스트(burst) 상황에서다. 평소에는 Node Pool 3대로 충분하지만, 이벤트 트래픽이 몰려서 순간적으로 Pod 50개가 필요한 경우, VM을 추가로 프로비저닝하면 수 분이 걸린다. Virtual Nodes는 ACI에 바로 Pod을 띄우므로 수 초 만에 스케일 아웃이 가능하다. 이벤트가 끝나면 ACI Pod이 내려가고 비용도 사라진다.
AWS에서는 EKS + Fargate가 비슷한 포지션이다.
ACR (Azure Container Registry)
ACR은 Azure에서 제공하는 Managed Private Docker Registry다. Docker Hub의 Private Repository와 같은 역할이지만, Azure 생태계와 긴밀하게 통합된다는 점이 차이다.
| 기능 | 설명 |
|---|---|
| Private Registry | 조직 내부의 컨테이너 이미지를 안전하게 저장 |
| AKS 통합 | AKS에서 ACR 이미지를 직접 pull (별도 인증 설정 불필요) |
| Geo-replication | 여러 Azure 리전에 이미지 복제, 글로벌 배포 시 pull 속도 향상 |
| ACR Tasks | Git push 시 이미지 자동 빌드 (CI/CD 파이프라인의 일부) |
| 취약점 스캔 | Microsoft Defender와 연동한 이미지 보안 스캔 |
각 클라우드 벤더의 Container Registry를 비교하면:
| 벤더 | 서비스명 | 특징 |
|---|---|---|
| Azure | ACR | AKS와 네이티브 통합, ACR Tasks |
| AWS | ECR | EKS/ECS와 IAM 기반 통합, 이미지 스캔 |
| GCP | Artifact Registry | GKE와 통합, 멀티 포맷(Docker, Maven, npm 등) |
실무에서는 Docker Hub Public 이미지를 ACR에 미러링해서 사용하는 경우가 많다. Docker Hub는 pull rate limit이 있고, 외부 네트워크를 거쳐야 하기 때문이다.
Azure CLI
Azure CLI(az)는 Azure 리소스를 터미널에서 관리하는 크로스 플랫폼 도구다. Azure Portal(웹 콘솔)에서 할 수 있는 거의 모든 작업을 CLI로 수행할 수 있다.
AWS CLI, GCP의 gcloud와 같은 포지션이다. 로컬에 설치할 수도 있고, 브라우저에서 Azure Cloud Shell을 통해 바로 사용할 수도 있다.
AKS 관련 주요 az 명령어:
# AKS 클러스터 생성
az aks create -g myResourceGroup -n myAKSCluster --node-count 3
# kubectl 인증 정보 가져오기
az aks get-credentials -g myResourceGroup -n myAKSCluster
# ACR 생성
az acr create -g myResourceGroup -n myRegistry --sku Basic
# AKS에 ACR 연결 (이미지 pull 권한 부여)
az aks update -g myResourceGroup -n myAKSCluster --attach-acr myRegistry
az aks get-credentials를 실행하면 ~/.kube/config에 해당 클러스터의 인증 정보가 추가되어, 로컬에서 kubectl 명령어를 바로 사용할 수 있게 된다.
2. 컨테이너 기반의 앱 개발 (1)
Azure Web App for Containers
AKS가 K8s 클러스터 전체를 운영하는 서비스라면, Web App for Containers는 훨씬 단순한 모델이다. Docker 이미지 하나를 올리면 웹 앱으로 바로 서비스되는 PaaS 기반 컨테이너 호스팅이다.
Azure App Service의 확장 기능으로, Docker Hub 또는 ACR에서 이미지를 pull하여 몇 초 만에 배포한다. 6주차에서 다뤘던 App Service의 컨테이너 버전이라고 이해하면 된다.
일반 App Service vs Web App for Containers:
| 항목 | App Service (코드 배포) | Web App for Containers |
|---|---|---|
| 배포 방식 | 소스 코드 / ZIP 배포 | Docker 이미지 배포 |
| 런타임 선택 | Azure가 제공하는 런타임만 | 어떤 런타임이든 이미지에 포함하면 됨 |
| 커스터마이징 | 제한적 | 완전한 환경 제어 |
| 적합한 상황 | 표준 런타임으로 충분한 경우 | 특수 런타임, 복잡한 의존성이 필요한 경우 |
Web App for Containers의 핵심 기능
간편한 배포 — Docker Hub나 ACR에서 이미지를 선택하면 플랫폼이 OS 패치, 용량 프로비저닝, 로드 밸런싱을 자동으로 처리한다. 개발자는 Dockerfile만 잘 작성하면 된다.
CI/CD 통합 — Docker Hub, ACR, GitHub와 연동하여 소스 코드 변경 시 자동으로 이미지 빌드 → Registry push → App Service 배포가 이루어진다. 배포 슬롯(Deployment Slot)을 사용하면 스테이징에서 테스트 후 프로덕션으로 무중단 전환(swap)이 가능하고, 문제가 생기면 즉시 롤백할 수 있다.
자동 스케일링 — 수평(인스턴스 추가) 및 수직(스펙 변경) 스케일링을 모두 지원한다. CPU 사용률, 메모리, HTTP 요청 수 등을 기준으로 스케일링 규칙을 세분화할 수 있다.
AKS vs Web App for Containers — 언제 뭘 쓸까?
| 기준 | Web App for Containers | AKS |
|---|---|---|
| 복잡도 | 낮음 (이미지만 올리면 끝) | 높음 (K8s 리소스 전체 관리) |
| 마이크로서비스 | 단일 컨테이너 또는 소수 | 수십~수백 개의 서비스 |
| 네트워크 제어 | 제한적 | Ingress, Service Mesh 등 세밀한 제어 |
| 비용 | App Service Plan 기반 | Node VM 기반 (세밀한 최적화 가능) |
| 적합한 팀 | K8s 경험이 없는 소규모 팀 | DevOps/Platform 엔지니어가 있는 팀 |
단순한 웹 앱이나 API 서버를 하나 띄우는 거라면 Web App for Containers가 압도적으로 편하다. 마이크로서비스 아키텍처로 여러 서비스를 운영해야 한다면 AKS가 맞다. AWS에서 ECS Fargate vs EKS 선택과 동일한 판단 기준이다.
3. 컨테이너 기반의 앱 개발 (2)
전체 배포 파이프라인
클라우드 기반으로 컨테이너 앱을 배포하는 전체 흐름을 정리하면:
개발자 PC → GitHub / Azure Repos → ACR (이미지 빌드·저장) → AKS / Web App for Containers
(코드 작성 + Dockerfile) (소스 코드 관리) (CI: 자동 빌드) (CD: 자동 배포)
각 단계에서 Azure 서비스가 어떤 역할을 하는지:
| 단계 | 도구 / 서비스 | 역할 |
|---|---|---|
| 소스 관리 | GitHub, Azure Repos | 코드 버전 관리, PR/MR |
| CI (빌드) | GitHub Actions, Azure Pipelines, ACR Tasks | Dockerfile → 이미지 빌드 → ACR push |
| CD (배포) | GitHub Actions, Azure Pipelines | ACR 이미지 → AKS Deployment 업데이트 또는 Web App 재배포 |
| 모니터링 | Azure Monitor, Application Insights, Log Analytics | 컨테이너 로그, 메트릭, 알림 |
Azure CLI를 활용한 자동화
GUI(Azure Portal)로 리소스를 만들 수도 있지만, 실무에서는 CLI 또는 IaC(Infrastructure as Code) 기반으로 관리하는 것이 표준이다. 이유는 명확하다 — 재현성과 자동화.
Web App for Containers 배포를 Azure CLI로 수행하는 흐름:
# 1. 리소스 그룹 생성
az group create -n myRG -l koreacentral
# 2. ACR 생성 + 이미지 빌드
az acr create -g myRG -n myacr --sku Basic
az acr build -r myacr -t myapp:v1 .
# 3. App Service Plan 생성 (Linux + 컨테이너)
az appservice plan create -g myRG -n myPlan --is-linux --sku B1
# 4. Web App for Containers 생성
az webapp create -g myRG -p myPlan -n mywebapp \
-i myacr.azurecr.io/myapp:v1
# 5. ACR 자격 증명 연결
az webapp config container set -g myRG -n mywebapp \
--docker-registry-server-url https://myacr.azurecr.io \
--docker-registry-server-user myacr \
--docker-registry-server-password $(az acr credential show -n myacr --query passwords[0].value -o tsv)
이 스크립트를 GitHub Actions workflow에 넣으면, 코드 push만으로 전체 배포가 자동화된다. Portal에서 마우스로 클릭하는 것은 학습용으로는 좋지만, 프로덕션 환경에서는 CLI/IaC가 원칙이다.
실습 진행




이후 실습에서 이미지 빌드를 진행하였지만. 2026년 6월 기준 해당 Dockerfile의 Debian 10이 지원 종료되어서 빌드가 불가능했기에, 코드를 조금 수정 한 뒤 빌드를 진행하였다.




이제 azure CLI를 이용한 쿠버네티스 사용을 진행해보자


그냥 바로 acr 생성하려하니 오류가 나서, 확인해보니까 아직 등록이 진행중이었다.
잠시 기다린 후 생성하니 잘 되는 모습.






이후 아래 URL의 명령어들을 차례로 잘 실행하다보면 웹 서비스 리소스를 만들 수 있다.

자습서: Azure App Service에서 사용자 지정 이미지 빌드 및 실행 - Azure App Service
사용자 지정 소프트웨어를 사용자 지정 컨테이너에 있는 App Service로 마이그레이션하는 방법에 대해 알아봅니다. 사용자 지정 이미지를 빌드하고 App Service에 배포합니다.
learn.microsoft.com


몇주 째 터미널 환경에서만 작업하다보니
좀 실습이 컴컴하고 지루하지만 (...)
확실히 유익하여 도움이된다.
정리
이번 주에는 클라우드 환경에서의 컨테이너 기술 활용을 다뤘다.
- AKS: Azure의 Managed K8s 서비스. Control Plane을 Azure가 관리하므로 운영 부담이 크게 줄어든다. Virtual Nodes(ACI 연동)로 버스트 트래픽에도 빠르게 대응 가능하다
- ACR: Azure의 Private Container Registry. AKS와 네이티브 통합되며, ACR Tasks로 이미지 빌드 자동화가 가능하다
- Azure CLI:
az명령으로 Azure 리소스를 터미널에서 관리. Portal 대비 재현성과 자동화에 유리하다 - Web App for Containers: Docker 이미지를 App Service에 배포하는 가장 간단한 방법. K8s 없이도 컨테이너 기반 서비스를 운영할 수 있다
- 선택 기준: 단일 앱/소규모 → Web App for Containers, 마이크로서비스/대규모 → AKS
- 배포 파이프라인: GitHub → ACR(빌드) → AKS/Web App(배포)의 CI/CD 흐름이 표준이다
다음 시간에는 클라우드에서 제공하는 AI 기술에 대해 알아본다.
'개인공부' 카테고리의 다른 글
| [AWS] 3. AWS 비용 구조 및 과금 모델 이해하기 (0) | 2026.06.09 |
|---|---|
| [Microsoft Azure] 11. AI 앱의 개발과 활용 - Azure AI 서비스 (0) | 2026.06.09 |
| [Microsoft Azure] 9. 컨테이너 기술의 이해 - 쿠버네티스 (1) | 2026.06.03 |
| [Microsoft Azure] 8. 컨테이너 기술의 이해 - 도커 (0) | 2026.06.03 |
| [Microsoft Azure] 7. 서버리스 서비스의 이해 (0) | 2026.05.19 |