[Kubernetes] 11. 워크로드 (4편) - Deployment 배포 전략

JIWON·2025년 7월 3일

Kubernetes

목록 보기

11/32

1. Deployment 업데이트 전략

Deployment가 기존 버전의 애플리케이션을 새로운 버전으로 교체할 때 사용하는 방식을 업데이트 전략이라고 한다. Deployment는 spec.strategy.type 필드를 통해 크게 두 가지 전략을 제공한다.

Recreate: 기존 버전을 모두 종료시킨 후, 새로운 버전을 한 번에 배포하는 방식.
RollingUpdate (기본값): 새로운 버전을 점진적으로 배포하면서 기존 버전을 점진적으로 종료시키는 방식.

1) 재생성(Recreate) 전략

재생성(Recreate) 전략은 모든 이전 버전(V1)의 파드를 한 번에 종료하고, 모든 새 버전(V2)의 파드를 일괄적으로 교체하는 방식이다.

장점: 구조가 단순하고 배포를 빠르게 교체할 수 있다.
단점: 모든 파드가 한 번에 종료되므로 서비스 다운타임이 발생한다. 또한 새로운 버전에 문제가 발생했을 때 대처가 늦어질 수 있다.

YAML 설정

spec.strategy.type 을 Recreate 로 명시한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment-recreate
spec:
  strategy:
    type: Recreate # Recreate 전략 사용
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    # ... 파드 템플릿 ...

2) 롤링업데이트(RollingUpdate) 전략

롤링 업데이트(Rolling Update)는 쿠버네티스의 표준 배포 방식으로, 새 버전의 파드를 하나씩 늘려가면서 기존 버전의 파드를 하나씩 줄여나가는 방식이다. 이 과정을 통해 서비스 중단 없이(zero-downtime) 업데이트를 진행할 수 있다.

장점: 다운타임 없이 안정적으로 배포할 수 있으며, 새 버전에 문제가 생기면 즉시 롤백하여 서비스 영향을 최소화할 수 있다.
단점: 배포가 완료되기까지 시간이 다소 소요될 수 있다.

롤링 업데이트 세부 설정

롤링 업데이트의 동작은 spec.strategy.rollingUpdate 필드의 maxSurge 와 maxUnavailable 옵션으로 정교하게 제어할 수 있다. 값은 정수 또는 퍼센트(%)로 지정할 수 있다.

maxSurge (기본값 25%): 롤링 업데이트 중 replicas 개수를 초과하여 최대로 더 생성할 수 있는 파드의 수를 지정한다. 이 값을 높이면 새 버전을 빠르게 배포할 수 있다.
maxUnavailable (기본값 25%): 롤링 업데이트 중 사용 불가능 상태가 되어도 되는 파드의 최대 개수를 지정한다. 이 값을 높이면 기존 버전을 빠르게 제거하여 배포 속도를 높일 수 있지만, 너무 높게 설정하면 남은 소수의 파드에 트래픽이 몰릴 수 있어 주의가 필요하다.

YAML 설정

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment-rollingupdate
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0 # 업데이트 중에도 최소 3개(replicas)의 파드는 항상 사용 가능해야 함
      maxSurge: 1       # 업데이트 중 최대 4개(3+1)의 파드가 존재할 수 있음
  selector:
    # ...

2. 고급 배포 전략 (Blue/Green, Canary)

쿠버네티스 Deployment만으로는 구현이 복잡하지만, 서비스(Service) 리소스나 Istio와 같은 서비스 메시 도구를 함께 사용하여 구현하는 고급 배포 전략들이다.

1) 블루/그린 (Blue/Green) 업데이트

애플리케이션의 이전 버전(블루)과 새 버전(그린)을 동시에 운영하는 방식이다. 두 개의 Deployment를 각각 배포한 후, 서비스 또는 라우터 단에서 트래픽을 한 번에 새 버전(그린)으로 전환한다.

장점: 새 버전에 문제가 생겼을 때 트래픽을 즉시 이전 버전(블루)으로 되돌릴 수 있어 매우 안정적이다.
단점: 이전 버전과 새 버전, 즉 두 배의 리소스(CPU, 메모리)가 필요하다.

2) 카나리 (Canary) 업데이트

카나리 업데이트는 새 버전의 애플리케이션을 일부 사용자에게만 먼저 공개하여 테스트하는 방식이다. 처음에는 5% 정도의 트래픽만 새 버전으로 보내고, 안정성이 검증되면 점차 트래픽을 늘려 최종적으로 100% 전환한다.

장점: 실제 사용자 트래픽을 통해 새로운 기능의 문제점을 조기에 발견하고, 서비스 전체에 미치는 영향을 최소화할 수 있다.
단점: 트래픽을 정교하게 분산하고 관리해야 하므로 구현이 복잡하다. 특히 UI/UX가 변경되는 경우, 사용자가 새로고침할 때마다 구/신 버전이 번갈아 보이는 문제를 방지하기 위해 스티키 세션(Sticky Session)과 같은 기술이 필요할 수 있다.

3. 기타 상세 업데이트 파라미터

Deployment에는 업데이트 동작을 더 세밀하게 제어할 수 있는 추가 파라미터들이 있다.

minReadySeconds: 새로 생성된 파드가 Ready 상태가 된 후, 실제로 '사용 가능'으로 간주되기까지 대기하는 최소 시간(초)이다. 이 시간 동안 파드에 문제가 없는지 확인할 여유를 가질 수 있다.
revisionHistoryLimit : 롤백을 위해 보관할 이전 ReplicaSet의 개수를 지정한다.
progressDeadlineSeconds: 업데이트가 진행 중일 때, 지정된 시간(초) 동안 아무런 진전이 없으면 업데이트가 실패했다고 판단하고 롤백을 시도하는 타임아웃 시간이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment-params
spec:
  minReadySeconds: 10
  revisionHistoryLimit: 2
  progressDeadlineSeconds: 600
  # ...