Azure Kubernetes Service(AKS)로의 무중단 마이그레이션

이 문서에서는 기존 워크로드를 AKS(Azure Kubernetes Service) 마이그레이션하고 가동 중지 시간을 최소화하거나 0으로 기존 AKS 클러스터에서 새 애플리케이션 버전을 릴리스하기 위한 실제적인 프로덕션 중심 접근 방식을 설명합니다.

빠른 답변: 마이그레이션의 경우 원본 및 AKS 환경을 병렬로 실행하고 트래픽을 점진적으로 이동합니다. 하나의 AKS 클러스터에서 애플리케이션을 정기적으로 릴리스할 때는 준비 상태 프로브, 제어된 트래픽 전환, 관측성 게이트, 그리고 검증된 롤백을 갖춘 롤링 업데이트, 카나리 배포 또는 클러스터 내 블루-그린 배포를 사용하세요.

빠른 운영 가이드: 무중단 AKS 마이그레이션을 위한 5단계

1. 타겟 AKS, 인증서, 네트워킹 및 관찰 가능성을 프로비저닝하세요.
2. 준비 상태 및 활동성 프로브, PodDisruptionBudget 및 리소스 요청을 사용하여 앱을 배포합니다.
3. 복제, CSI 스냅샷 또는 Velero를 사용해 데이터를 동기화합니다.
4. Traffic Manager에서 상대 DNS 가중치를 사용하거나 수신 또는 서비스 메시 라우팅을 통해 정확한 요청 비율을 사용하여 트래픽을 점진적으로 이동합니다.
5. 안정성 조건이 통과될 때 SLO 게이트의 유효성을 검사하고 이전 인프라를 해제합니다.

당신은 다음을 배우게 됩니다:

• 클러스터를 교체하지 않고 기존 AKS 클러스터에서 새 애플리케이션 버전을 릴리스합니다.
• Blue-Green, 카나리아 및 롤링 DNS 마이그레이션 전략을 비교합니다.
• AKS 관련 명령을 사용하여 마이그레이션 전 준비 검사 목록을 실행합니다.
• AKS 및 Azure Traffic Manager 사용하여 전체 Blue-Green 클러스터 마이그레이션을 수행합니다.
• CSI 스냅샷, Azure Files 또는 Velero를 사용하여 영구 데이터를 마이그레이션합니다.
• 전환 전에 롤백 계획을 준비하세요.

마이그레이션 전략 비교

이 비교를 사용하여 위험 허용 범위, 관찰성 완성도 및 롤백 요구 사항에 맞는 마이그레이션 방법을 선택합니다.

Strategy	트래픽 영향	롤백 속도	복잡성	AKS 기능 및 Azure 서비스
Blue-Green(클러스터 또는 네임스페이스)	녹색이 정상인 경우에만 트래픽이 전환되므로 최소	트래픽을 파란색으로 다시 전환하여 매우 빠릅니다.	중간, 중복 환경 및 트래픽 라우팅이 필요하기 때문에	Azure Traffic Manager, LoadBalancer 공용 IP 주소, 인그레스
카나리아	트래픽이 점진적으로 이동하기 때문에 매우 낮음	카너리 비중을 줄이거나 카너리 포드 수를 축소하여 신속하게 대응하세요.	트래픽 분할 및 관찰이 필요하기 때문에 보통 높음	인그레스(nginx 또는 게이트웨이 API), 서비스 메시(Istio 또는 Linkerd), AKS 인그레스 추가 기능
롤링 DNS(TTL 기반)	DNS TTL에 따라 다릅니다. 짧은 TTL은 영향을 낮춥니다.	DNS 캐시가 롤백을 지연할 수 있기 때문에 중간	낮음, 설정은 간단하지만 정확도가 낮기 때문에	Azure DNS, 낮은 TTL 기록, LoadBalancer 또는 인그레스

워크로드 의사 결정 매트릭스

워크로드 유형별 빠른 전략 권장 사항이 필요한 경우 이 표를 사용합니다.

워크로드 유형	권장되는 전략	이유	비용 및 복잡성
무상태 웹/API	카너리, 이후 파란색-초록색으로 최종 전환	빠른 롤백을 사용하여 점진적 위험 감소	중간
상태를 유지하는 데이터베이스 기반 앱	파란색-초록색 + 복제 및 촉진 데이터 경로	가장 강력한 롤백 제어와 명확한 페일백 경로	높음
파일 사용량이 많은 워크로드	파란색-초록색 + Azure Files 복사/스냅샷	전환하기 전에 데이터 패리티의 더 쉬운 유효성 검사	보통 높음
장기 실행 작업/작업자	대기열 드레인이 포함된 롤링 업데이트 또는 유지 보수 기간	사용자 관련 영향 감소, 더 간단한 라우팅	낮음-중간

점진적 배포 도구 옵션

• 수동 가중치 라우팅(Traffic Manager + Ingress 또는 LoadBalancer): 운영자가 직접 제어해야 하고 종속성이 단순한 경우에 가장 적합합니다.
• 서비스 메시 라우팅(Istio 또는 Linkerd): 세분화된 라우팅, 재시도 및 정책 제어가 필요한 경우에 가장 적합합니다.
• Argo 롤아웃 또는 플래그: 자동화된 점진적 전달, 메트릭 분석 및 자동 롤백을 원하는 경우에 가장 적합합니다.

전역 DNS 수준의 가중치 조정을 위해 Traffic Manager를 사용하고, 클러스터 내부에서 자동화된 롤아웃 분석이 필요한 경우 Argo Rollouts 또는 Flagger와 함께 사용하세요.

기존 AKS 클러스터에서 애플리케이션 릴리스

되풀이 애플리케이션 릴리스에는 두 번째 클러스터 또는 DNS 중단이 필요하지 않습니다. AKS에서 이미 실행 중인 상태 비저장 애플리케이션의 경우 여러 복제본과 RollingUpdate 전략을 사용하는 Kubernetes Deployment를 사용합니다. Kubernetes는 동일한 클러스터에 새 버전 Pod를 만들고, 준비가 될 때까지 기다린 다음, 이전 버전 Pod를 점진적으로 제거합니다.

다음 예제에서는 Kubernetes가 한 번에 하나의 추가 Pod를 시작하는 동안 모든 기존 복제본을 사용할 수 있도록 유지합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  minReadySeconds: 10
  progressDeadlineSeconds: 600
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:v2
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]

클러스터에 서지 Pod를 수용할 여유가 있는지 확인합니다. 매니페스트를 적용하고, 롤아웃을 모니터링하고, 새 이미지를 확인합니다.

kubectl apply -f manifests/app-deployment.yaml
kubectl rollout status deployment/myapp --timeout=10m
kubectl get pods -l app=myapp -o custom-columns=NAME:.metadata.name,IMAGE:.spec.containers[0].image,READY:.status.containerStatuses[0].ready

이후 릴리스의 경우 이미지를 업데이트하고 배포 롤아웃을 모니터링합니다.

kubectl set image deployment/myapp myapp=myregistry.azurecr.io/myapp:v3
kubectl rollout status deployment/myapp --timeout=10m

롤아웃 중에 오류 속도, 대기 시간, Pod 준비 상태 및 비즈니스 트랜잭션을 모니터링합니다. 게이트가 실패하면 릴리스를 중지하거나 실행 취소합니다.

kubectl rollout pause deployment/myapp
kubectl rollout undo deployment/myapp
kubectl rollout status deployment/myapp --timeout=10m

PodDisruptionBudget는 노드 드레인과 같은 자발적 축출 작업 중에 레플리카를 보호하지만, 애플리케이션 롤아웃 중에 Deployment가 파드를 교체하는 방식은 제어하지 않습니다. 릴리스 가용성을 제어하려면 maxSurge 및 maxUnavailable을 사용하세요. 요청 수준의 트래픽 비율이나 자동화된 메트릭 분석이 필요한 애플리케이션의 경우, 동일한 클러스터에서 안정 버전과 카나리 버전을 배포하고 인그레스 컨트롤러, 서비스 메시, Argo Rollouts 또는 Flagger를 사용하여 트래픽을 점진적으로 전환합니다.

시작하기 전 주의 사항:

• Azure CLI 버전 2.59.0 이상.
• kubectl 원본 클러스터에 연결됩니다.
• 클러스터, 네트워킹 및 ID를 만들고 관리하는 AKS 권한
• 테스트된 애플리케이션 상태 엔드포인트(예: /healthz.
• 트래픽 전환 전에 롤백 담당자와 롤백 체크리스트가 승인되어야 합니다.
• DNS TTL 감소 계획은 중단하기 최소 24-48시간 전에 준비되었습니다.

TLS 및 인증서 사전 프로비전

교통 흐름 전환 전 녹색 환경에서의 허가증 발급. 현재 환경에서 TLS 종료를 수행하는 경우, 전환하기 전에 인증서를 Kubernetes 시크릿으로 내보내고 가져오거나 cert-manager를 구성하세요.

# Example: create a TLS secret in the target namespace
kubectl create secret tls myapp-tls \
  --cert ./tls.crt \
  --key ./tls.key \
  --namespace production

ACME(예: 암호화)를 사용하는 경우 중단 전에 도메인 유효성 검사를 완료하여 HTTPS 오류를 방지합니다.

마이그레이션 전 준비 상태 검사 목록

마이그레이션하기 전에 이러한 검사를 실행합니다. 버전 제어 또는 보안 스토리지에 모든 내보내기 저장

원본 클러스터에서 Kubernetes 리소스 내보내기

kubectl --context=current-prod-cluster get all --all-namespaces -o yaml > exports/all-namespaces-all-resources.yaml
kubectl --context=current-prod-cluster get deployments,statefulsets,daemonsets --all-namespaces -o yaml > exports/workloads.yaml
kubectl --context=current-prod-cluster get svc --all-namespaces -o yaml > exports/services.yaml
kubectl --context=current-prod-cluster get configmap,secret --all-namespaces -o yaml > exports/configs-secrets.yaml
kubectl --context=current-prod-cluster get pvc --all-namespaces -o yaml > exports/pvcs.yaml
kubectl --context=current-prod-cluster get ingress --all-namespaces -o yaml > exports/ingress.yaml

Important

내보낸 비밀 매니페스트를 중요한 데이터로 처리합니다. 보안 시스템에만 저장합니다.

구독, 할당량 및 네트워킹 필수 구성 요소 유효성 검사

az account show --query "{name:name, id:id, tenantId:tenantId}" -o table
az configure --defaults location=eastus resource_group=rg-aks-migration
az vm list-usage --location eastus -o table
az network public-ip list --resource-group rg-aks-migration -o table

ID 및 RBAC 요구 사항 유효성 검사

az aks show --resource-group rg-aks-migration --name existing-aks --query aadProfile
az role assignment list --resource-group rg-aks-migration -o jsonc
az identity list --resource-group rg-aks-migration -o table

계속하기 전에 다음 항목을 확인합니다.

• 클러스터 관리 그룹 및 Entra ID 통합 모델
• 관리형 ID 범위 및 역할 할당.
• 대상 환경에서 사용하도록 설정된 로깅, 메트릭 및 경고입니다.

전략 가이드

다음 섹션에서는 워크로드에 적응할 수 있는 하나의 완전한 Blue-Green 예제와 두 개의 짧은 패턴(카나리아 및 롤링 DNS)을 제공합니다.

Blue-Green 클러스터 마이그레이션

이 시나리오에서는 현재 프로덕션 트래픽이 app.example.com의 레거시 환경에서 제공됩니다. 새 AKS 클러스터()aks-green를 만들고, 워크로드를 배포하고, Azure Traffic Manager 이전 엔드포인트와 녹색 엔드포인트를 모두 등록하고, 트래픽을 점진적으로 전환합니다.

기본 마이그레이션 지침은 AKS(Azure Kubernetes Service) 대한 마이그레이션 개요를 참조하세요.

1. 녹색 AKS 클러스터 만들기

RG=rg-aks-migration
LOCATION=eastus
CLUSTER=aks-green
NODE_COUNT=3

az group create --name $RG --location $LOCATION

az aks create \
  --resource-group $RG \
  --name $CLUSTER \
  --location $LOCATION \
  --node-count $NODE_COUNT \
  --enable-managed-identity \
  --network-plugin azure \
  --load-balancer-sku standard \
  --generate-ssh-keys \
  --enable-addons monitoring \
  --attach-acr <yourACRName> \
  --yes

클러스터 자격 증명 가져오기:

az aks get-credentials --resource-group $RG --name $CLUSTER --overwrite-existing
kubectl config use-context $CLUSTER

2. 상태 점검 및 중단 제어 기능을 사용하여 워크로드를 배포합니다.

manifests/app-deployment.yaml을(를) 만듭니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
        version: green
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: myapp
        image: myregistry.azurecr.io/myapp:green
        resources:
          requests:
            cpu: 250m
            memory: 256Mi
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10
          failureThreshold: 3
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 30"]
---
apiVersion: v1
kind: Service
metadata:
  name: myapp-lb
  labels:
    app: myapp
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  externalTrafficPolicy: Local

리소스 요청이 예제입니다. 대상 클러스터가 프로덕션 일정 및 용량 동작을 나타내도록 관찰된 워크로드 사용량 및 부하 테스트 결과에서 CPU 및 메모리 요청 크기를 조정합니다.

externalTrafficPolicy: Local 는 원본 IP를 유지하지만 노드당 사용 가능한 백 엔드 엔드포인트를 줄일 수 있습니다. 고정 세션 애플리케이션의 경우 마이그레이션 전에 세션 상태(예: Azure Cache for Redis)를 외부화하여 트래픽 이동 중 선호도 관련 중단을 방지합니다.

manifests/pdb.yaml을(를) 만듭니다.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

리소스를 적용하고 롤아웃을 확인합니다.

kubectl apply -f manifests/app-deployment.yaml
kubectl apply -f manifests/pdb.yaml
kubectl rollout status deployment/myapp
kubectl get svc myapp-lb -o wide

3. 녹색 엔드포인트 가져오기

kubectl get svc myapp-lb -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

다음 단계에서 반환된 IP를 사용합니다.

4. Azure Traffic Manager 프로필 및 엔드포인트 만들기

TM_PROFILE=myapp-tm

az network traffic-manager profile create \
  --name $TM_PROFILE \
  --resource-group $RG \
  --routing-method Weighted \
  --unique-dns-name myapp-tm-$RANDOM \
  --ttl 30 \
  --protocol http \
  --path /healthz \
  --interval 30 \
  --timeout 10

이전 엔드포인트를 추가합니다.

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name old-endpoint \
  --target old.example.com \
  --endpoint-status Enabled \
  --weight 100

녹색 엔드포인트를 추가합니다.

az network traffic-manager endpoint create \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --type externalEndpoints \
  --name green-endpoint \
  --target <green-endpoint-ip> \
  --endpoint-status Disabled \
  --weight 0

명령 세부 정보는 az network traffic-manager 프로필 및 az network traffic-manager 엔드포인트를 참조하세요.

5. 트래픽을 green 환경으로 점진적으로 전환

낮은 무게로 시작하고 상태 및 대기 시간을 관찰합니다.

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.endpointStatus=Enabled \
  --weight 10

az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=90

기존 환경과 녹색 환경의 상대적 가중치를 50:50으로 설정한 다음 10:90으로 변경하는 등 단계적으로 가중치를 조정하면서 계속 진행합니다. Traffic Manager는 이러한 상대 가중치에 따라 각 DNS 쿼리에 대한 엔드포인트를 선택합니다. 가중치는 정확한 요청 비율을 보장하지 않습니다. DNS 응답은 클라이언트 및 재귀 확인자에 의해 캐시되며 관찰된 배포를 왜곡할 수 있습니다. 계속하기 전에 각 단계를 최소한 프로필 TTL에 더해 대표적인 애플리케이션 트래픽을 측정할 수 있을 만큼 충분한 시간 동안 유지하십시오. 요청별로 세밀한 트래픽 분산이 필요한 경우 L7 인그레스 또는 서비스 메쉬를 사용하세요.

전환 기준, 모니터링 게이트 및 롤백 플레이북

각 트래픽이 증가하기 전에 명시적 게이트를 정의합니다.

예제 게이트

• HTTP 5xx가 3분 연속으로% 1을 초과하면 롤백합니다.
• p95 대기 시간이 5분 동안 기준선을 200ms 이상 초과하면 롤백합니다.
• 데이터베이스 복제 지연 시간이 RPO 임계값을 초과하는 경우 롤아웃을 일시 중지합니다.
• pod 재시작률이 정상 기준치를 넘어서 급증하면 롤아웃을 일시 중지하세요.

롤 포워드 순서

1. 트래픽 가중치를 소폭으로 늘리세요.
2. SLO 게이트 및 비즈니스 스모크 테스트의 유효성을 검사합니다.
3. 모든 게이트가 보류 기간 동안 통과된 경우에만 진행합니다.

롤백 시퀀스

1. 이전 엔드포인트로 라우팅을 다시 시작합니다. 클라이언트는 TTL이 만료될 때까지 캐시된 DNS 응답을 계속 사용할 수 있습니다.
2. 필요한 경우 배포를 실행 취소하거나 녹색을 0으로 조정합니다.
3. 이전 환경 상태 및 데이터 무결성의 유효성을 다시 검사합니다.

# Restore old endpoint to 100
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name old-endpoint \
  --set properties.weight=100

# Set green endpoint to 0
az network traffic-manager endpoint update \
  --resource-group $RG \
  --profile-name $TM_PROFILE \
  --name green-endpoint \
  --set properties.weight=0

# Optional Kubernetes rollback options
kubectl rollout undo deployment/myapp
kubectl scale deployment myapp --replicas=0

6. 필요 시 빠르게 롤백

오류가 증가하거나 SLO 임계값이 실패하는 경우:

• 이전 엔드포인트 가중치를 다시 설정하고 녹색으로 1000설정합니다.
• 추가 롤아웃을 일시 중지하고 필요에 따라 녹색 Pod를 축소합니다.

kubectl scale deployment myapp --replicas=0

카나리 마이그레이션(짧은 안내)

최소 중복 인프라를 사용하여 증분 릴리스 제어를 원하는 경우 카나리아를 사용합니다.

1. 안정적인 워크로드 및 카나리아 워크로드를 배포합니다.
2. 트래픽의 작은 비율을 카나리아로 라우팅합니다.
3. 키 신호를 관찰한 다음 늘리거나 롤백합니다.

nginx 카너리 인그레스 주석 예시:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

상태가 안정적으로 유지됨에 따라 단계별로 증가 canary-weight 합니다.

롤링 DNS 마이그레이션 (간단한 안내)

DNS 전환이 기본 트래픽 제어 메커니즘인 경우 롤링 DNS를 사용합니다.

캐시가 사용 중단되기 최소 24~48시간 전에 DNS TTL을 낮은 값으로 설정합니다. 마이그레이션이 안정화된 후 더 높은 TTL을 복원하여 쿼리 볼륨 및 확인자 변동을 줄입니다.

1. DNS TTL을 낮춥니다(예: 30초).
2. AKS 엔드포인트를 배포합니다.
3. DNS A/CNAME 레코드를 업데이트합니다.
4. 전파 및 상태를 관찰하세요.

예제 A 레코드 업데이트:

RG=rg-aks-migration

az network dns record-set a update \
  --resource-group $RG \
  --zone-name example.com \
  --name app \
  --set ttl=30

az network dns record-set a remove-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 13.78.1.2

az network dns record-set a add-record \
  --resource-group $RG \
  --zone-name example.com \
  --record-set-name app \
  --ipv4-address 52.160.1.100

영구 볼륨에 대한 데이터 마이그레이션

상태 유지 마이그레이션은 일반적으로 가장 위험도가 높은 구역입니다. 스토리지 유형 및 일관성 요구 사항과 일치하는 데이터 경로를 선택합니다.

데이터베이스 전략

가동 중지 시간 및 일관성 요구 사항에 맞는 데이터베이스 마이그레이션 패턴을 선택합니다.

패턴	장점	장단점	일반적인 용도
외부 데이터베이스(공유)	가장 간단한 앱 마이그레이션 경로, 앱 이동 중 DB 중단 없음	공유 폭발 반경, 잠재적 성능 결합	이전 및 새 앱에서 공유하는 기존 관리형 PaaS DB
복제 및 승격	통제된 전환 및 롤백 시점	복제 및 승격을 위한 운영 오버헤드	엄격한 RPO 요구 사항이 있는 중요 업무용 상태 저장형 워크로드
이중 쓰기(임시)	가동 중지 시간을 거의 0으로 줄인 앱 전환 지원	복잡한 조정 및 멱등성 요구 사항	완성도 높은 데이터 파이프라인을 사용하는 이벤트 기반 시스템

CDC 및 마이그레이션 오케스트레이션의 경우 Azure Database Migration Service 및 Debezium을 평가합니다. 전환 과정에서 이전 버전과 새 버전 앱의 호환성을 유지하려면 확장 -> 마이그레이션 -> 계약 스키마 변경 기능을 사용하세요.

Azure Disk CSI 스냅샷

스냅샷 CRD 및 스냅샷 컨트롤러가 설치된 경우 블록 볼륨에 대해 CSI 스냅샷을 사용하세요.

예 VolumeSnapshotClass:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-azuredisk-snapclass
driver: disk.csi.azure.com
deletionPolicy: Delete

기존 PVC의 스냅샷 예제:

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: mydata-snapshot
spec:
  volumeSnapshotClassName: csi-azuredisk-snapclass
  source:
    persistentVolumeClaimName: mydata-pvc

스냅샷에서 PVC 복원 예제:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mydata-pvc-restored
spec:
  storageClassName: managed-csi
  dataSource:
    name: mydata-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi

Important

스냅샷은 일반적으로 애플리케이션 일관성이 아닌 크래시 일관성을 유지합니다. 데이터베이스의 경우 복제 또는 애플리케이션 인식 백업 및 복원을 사용합니다.

Azure Files

파일 기반 워크로드의 경우:

• 원본 파일 공유에 대한 스냅샷을 만들거나 계획을 복사합니다.
• AzCopy 같은 도구를 사용하여 데이터를 복사합니다.
• 대상 공유에 대한 StorageClass 및 PVC 구성을 업데이트합니다.

복사 패턴 예제:

az storage share snapshot --account-name mystorage --name myshare
azcopy copy "https://<src>/myshare" "https://<dest>/myshare" --recursive

Velero 백업 및 복원

Azure 플러그 인으로 구성된 경우 PV 데이터를 포함하여 클러스터 리소스 백업 및 복원에 Velero를 사용합니다.

RG=rg-aks-migration

velero install \
  --provider azure \
  --bucket my-velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config resourceGroup=$RG,storageAccount=myvelerostorage,subscriptionId=<subscription-id>

velero backup create pre-migration-backup --include-namespaces my-namespace
velero restore create --from-backup pre-migration-backup

Velero 설명서를 참조하고 AKS에서 Azure 디스크 CSI 스냅샷을 사용합니다.

관찰 가능성 및 자동화된 롤백

트래픽이 이동하기 전에 다음 신호를 계측합니다.

• HTTP 요청 속도 및 성공률입니다.
• HTTP 5xx 오류 비율입니다.
• p95 및 p99 요청 대기 시간.
• Pod 재시작 빈도 및 준비 상태 실패
• 노드 압력 및 대기 중인 파드 수
• 데이터베이스 복제 지연.
• 비동기 워크로드의 큐 깊이입니다.

예제 PromQL 스타일 경고 조건:

# Rollback gate: 5xx error rate over 1%
sum(rate(http_requests_total{status=~"5.."}[3m]))
/
sum(rate(http_requests_total[3m])) > 0.01

# Rollback gate: p95 latency exceeds 200ms over baseline target
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.2

게이트 실패 시 자동으로 일시 중지되거나 롤백되도록 알림을 롤아웃 컨트롤러(수동 런북, Argo Rollouts 또는 Flagger)와 연동하세요.

테스트 및 유효성 검사 레시피

섀도 트래픽

최종 사용자에게 녹색 응답을 반환하지 않고 프로덕션 트래픽 조각을 녹색으로 미러링합니다. 이렇게 하면 사용자 위험이 낮은 실제 부하에서 동작의 유효성을 검사합니다.

연기 테스트

예를 들어, 가중치가 증가할 때마다 중요 비즈니스용 검사를 실행합니다.

• 로그인 흐름
• 결제 또는 체크 아웃 흐름
• API 경로 읽기 및 쓰기
• 백그라운드 작업 완료

부하 테스트

k6, hey 또는 Azure Load Testing 같은 도구를 사용하여 최종 중단 전에 용량 및 자동 크기 조정 동작의 유효성을 검사합니다.

기능 표시기

기능 플래그를 사용하여 배포를 릴리스에서 분리합니다. 기능 플래그는 다시 배포하지 않고 위험한 코드 경로를 사용하지 않도록 설정해야 하는 경우 두 번째 안전 계층을 제공할 수 있습니다.

프로덕션 전환 체크리스트

• [ ] 준비 상태 및 활동성 프로브가 진정한 봉사 준비를 반영하는지 확인합니다.
• [ ] 부하 상태에서 preStop 및 terminationGracePeriodSeconds 값을 검증하세요.
• [ ] 업그레이드 및 제거 이벤트에 대한 PodDisruptionBudget 값을 확인합니다.
• [ ] 예상 마이그레이션 트래픽 급증에 대한 자동 크기 조정 설정을 확인합니다.
• [ ] 트래픽 진입점을 통해 엔드투엔드 상태 점검을 검증합니다.
• [ ] 전환 전에 로그, 메트릭, 경고 및 합성 점검을 검증합니다.
• [ ] 롤백 책임자, 롤백 트리거 기준 및 롤백 운영 절차서를 확인합니다.
• [ ] 새 엔드포인트에 대한 NSG, 방화벽 및 상태 프로브 규칙의 유효성을 검사합니다.
• [ ] TLS 종료 동작의 유효성을 검사하고 CORS 설정이 이전 환경과 일치하는지 확인합니다.
• [ ] 임시 청록색 겹침 기간에 대한 비용 계획의 유효성을 검사합니다.

롤백 검사 목록

1. 트래픽을 이전 엔드포인트(Traffic Manager 가중치 또는 DNS 롤백)로 이동합니다.
2. 녹색 배포를 일시 중지하거나 축소합니다.
3. 필요한 경우 이전 구성 또는 비밀을 복원합니다.
4. 정상 작업을 다시 시작하기 전에 이전 환경 상태의 유효성을 다시 검사합니다.

다음 단계

• AKS(Azure Kubernetes Service) 대한 마이그레이션 개요를 검토합니다.
• AKS 프로덕션 업그레이드 전략을 검토합니다.
• AKS에서 파란색-녹색 노드 풀 업그레이드를 검토합니다.
• Azure Traffic Manager 설명서를 검토합니다.