[CKAD] Kubernetes Deployment Strategies and Rollout

Deployment (배포): 쿠버네티스에서 Pod와 ReplicaSet을 관리하는 최상위 오브젝트

• 목적: 애플리케이션 배포, 업데이트, 롤백을 자동화하여 운영의 편의성을 제공합니다.

주요 명령어

• kubectl create deployment nginx --image=nginx:1.16: 새로운 Deployment를 생성합니다.
• kubectl get deployments: 현재 클러스터의 Deployment 목록을 확인합니다.
• kubectl describe deployment <이름>: 특정 Deployment에 대한 상세 정보를 확인합니다.
• kubectl delete deployment <이름>: Deployment를 삭제합니다.

Rollout (롤아웃): Deployment의 배포 진행 상태

배포 상태는 Deployment가 처음 만들어질 때, 또는 업데이트가 이루어질 때 관리됩니다.

언제 Rollout이 생기나?

• Deployment를 처음 만들 때(리비전 1 생성)
• Deployment를 업데이트할 때(이미지 변경, replica 개수 수정 등)

주요 명령어

• kubectl rollout status deployment <이름>: 현재 배포 진행 상황을 확인합니다.
• kubectl rollout pause deployment <이름>: 배포 상태를 일시적으로 중지합니다.
• kubectl rollout resume deployment <이름>: 중지된 배포를 재개합니다.

Revision (리비전): Deployment의 버전 이력

Deployment에 변경이 발생할 때마다 새로운 Revision이 추가됩니다.

주요 명령어

• kubectl rollout history deployment <이름>: Deployment의 리비전 이력을 확인합니다.
• kubectl rollout history deployment <이름> --revision=N: 특정 리비전에 대한 상세 정보를 확인합니다.

Change-cause (변경 원인): 리비전별로 변경된 이유 기록

--record 옵션을 사용하면, Deployment를 업데이트할 때 어떤 명령으로 변경했는지 기록할 수 있습니다.

주요 명령어

• kubectl set image deployment nginx nginx=nginx:1.17 --record: 이미지 업데이트와 동시에 변경 원인 기록.
• kubectl edit deployment nginx --record: YAML을 편집하며 변경 원인 기록.
• kubectl rollout history deployment nginx: 리비전 목록에서 change-cause를 확인합니다.

Rollback (롤백): 이전 리비전으로 되돌리기

Deployment를 이전 리비전으로 되돌리는 방법입니다.

주요 명령어

• kubectl rollout undo deployment <이름>: 직전 리비전으로 롤백합니다.
• kubectl rollout undo deployment <이름> --to-revision=N: 특정 리비전으로 롤백합니다.
• kubectl describe deployment <이름> | grep -i image: 롤백 후 실제 이미지 버전 확인합니다.

배포 전략 (Deployment Strategies)

Recreate (구버전 전부 종료 후 신버전 전부 생성)

• 특징: 구버전 Pod 전부 삭제 후 신버전 Pod 전부 생성
• 장점: 단순하고 깨끗한 전환
• 단점: 배포 중 다운타임 발생, 사용자 서비스 중단
• 사용 시기:
  • 다운타임 허용되는 내부 시스템
  • DB 스키마 충돌 등 구/신버전 동시 실행 불가할 때
  • 테스트/개발 환경

Rolling Update (Default)

• 특징: 구버전 Pod를 하나씩 줄이고 동시에 신버전 Pod를 하나씩 늘림
• 장점: 무중단 배포, 점진적 교체
• 단점: 배포 속도가 느리고 점진적인 교체가 이루어짐
• 사용 시기:
  • 일반적인 웹 서비스
  • 실시간 서비스가 필요한 경우(무중단 배포)
  • 대부분의 프로덕션 서비스

추가 제어 옵션:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # 동시에 내려갈 Pod 수
      maxSurge: 1         # 동시에 더 올라갈 Pod 수

Blue-Green (블루-그린 배포)

• 특징: 구버전(Blue)과 신버전(Green)을 동시에 실행한 뒤, 트래픽을 신버전으로 전환합니다.
• 장점: 트래픽 스위치 후 빠른 롤백 가능, 신버전 검증 후 전환
• 단점: 리소스 2배 소모 (구버전과 신버전이 동시에 실행됨)
• 사용 시기:
  • 대규모 릴리즈
  • 장애 리스크가 큰 배포
  • 신버전 검증 후 안정적으로 전환해야 할 때

예시:

# v1 배포 (Blue)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      version: v1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
        - name: myapp
          image: myapp:v1

# v2 배포 (Green)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 5
  selector:
    matchLabels:
      app: myapp
      version: v2
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
        - name: myapp
          image: myapp:v2

Canary (카나리 배포)

• 특징: 신버전을 일부 Pod에만 배포하여 트래픽 일부만 신버전으로 유입하고 안정성 검증 후 점진적으로 전체로 확산
• 장점: 리스크 최소화, 사용자 기반 검증
• 단점: 세밀한 비율로 트래픽을 제어하려면 Istio나 Linkerd와 같은 서비스 메시 사용 필요

예시:

# Primary 배포 (구버전, 다수 Pod)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-primary
spec:
  replicas: 5
  selector:
    matchLabels:
      app: frontend
      version: v1
  template:
    metadata:
      labels:
        app: frontend
        version: v1
    spec:
      containers:
        - name: myapp
          image: myapp:v1

# Canary 배포 (신버전, 소수 Pod)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 1   # 소량만 배포
  selector:
    matchLabels:
      app: frontend
      version: v2
  template:
    metadata:
      labels:
        app: frontend
        version: v2
    spec:
      containers:
        - name: myapp
          image: myapp:v2

서비스 (두 버전 모두 선택)

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  selector:
    app: frontend   # version은 구분 안 함
  ports:
    - port: 80
      targetPort: 8080

배포 전략 비교

전략	특징	장점	단점	사용 시기
Recreate	구버전 Pod 전부 종료 후 신버전 전부 생성	단순, 깨끗한 전환	다운타임 발생, 사용자 서비스 중단	- 다운타임 허용되는 내부 시스템 - DB 스키마 충돌 등 구/신버전 동시 실행 불가할 때
Rolling Update	구버전 Pod 하나씩 줄이고 신버전 Pod 하나씩 늘림	무중단 배포, 안정적	배포 속도 느림	- 일반적인 웹 서비스 - 실시간 서비스(무중단 필요)
Blue-Green	Blue(구버전)와 Green(신버전) 동시 실행, 트래픽 스위치로 전환	빠른 롤백, 안정적인 전환	리소스 소모 2배	- 대규모 릴리즈 - 장애 리스크가 큰 배포
Canary	일부 Pod에 신버전만 배포, 점진적으로 전체 확산	리스크 최소화, 안정성 검증	세밀한 트래픽 제어 어려움	- 새 기능/버전 점진적 도입 - 리스크를 최소화하고 실서비스 검증 필요