0. 사전지식

 이전 [4] Kubernetes Deployment 글에서는, Deployment가 ReplicaSet에 비해 버전 관리와 롤백이 가능하다는 점을 설명한 바 있다. 즉, 기존의 전통적인 배포 방식과 달리, 서비스를 중단하지 않고도 점진적으로 배포하거나, 이전 버전으로 손쉽게 되돌릴 수 있다는 점이 큰 장점이다. 이번 포스팅에서는 Kubernetes에서 제공하는 대표적인 배포 전략 4가지를 소개하, 각 전략의 동작 방식과 함께 실습 코드도 함께 다뤄보도록 하겠다.

 

1. Deployment Strategy란?

Deployment Strategy란, 애플리케이션에 변경 사항(업데이트, 수정 등)을 적용할 때 어떤 방식으로 배포를 진행할 것인지를 정의하는 전략이다. 핵심 목적으로는 서비스 무중단 또는 최소한의 다운타임으로 배포 진행, 문제 발생 시 빠른 롤백 대응, 트래픽 분산 및 모니터링 기반의 안정적인 릴리즈 수행이 있다. 

2. Deployment Strategy 종류

2.1. Recreate 전략

 기존 Pod를 모두 중지한 뒤, 업데이트 된 파드(Pod)들을 한 번에 다시 시작하는 방식이다. 사실상 실무 운영에서는 사용되지 않는다.

Recreate

장점 : 간단한 배포에 적합하며 전체 상태 초기화가 가능하다
단점 : 어플리케이션의 종료 및 부팅시간에 따른 다운타임이 발생하기 때문에 민감한 서비스에는 부적합하다.

 

2.2. Rolling Update 전략

쿠버네티스 Deployment의 기본 전략으로, 클러스터 다운타임 없이 이전 버전의 Pod를 새 버전의 Pod로 하나씩 천천히 교체하는 방식이다.

Rolling Update

장점 : 인스턴스 전반에 걸쳐 버전을 천천히 릴리즈 하기 때문에, 데이터를 처리할 수 있는 상태 저장(Stateful) 애플리케이션에 유용하다.
단점 : 롤 아웃이나 롤백을 위한 시간이 소요되며 트래픽을 컨트롤할 방법이 없다

 

2.3. Blue/Green 전략

인스턴스의 이전 버전(Blue)과 함께 앱의 최신 버전(Green)을 동일한 수만큼 배포하는 방식이다. 사용자 트래픽을 이전 인스턴스에서 최신 인스턴스로 전환할 수 있으며 신 버전에 문제가 있는 경우 이전 버전으로 쉽게 다시 전환이 가능하다. 만약 최신 버전이 잘 작동하면 이전 버전을 제거한다.

Blue / Green

장점 : 롤 아웃이나 롤백이 매우 빠르며, 전체 애플리케이션 상태 버전을 관리하기 용이하다.
단점 : 2배의 리소스가 필요하며 트래픽 전환 작업이 추가적으로 필요하다.

 

2.4. Canary 전략

Canary

일부 트래픽만 새로운 버전에 전달하여 점진적으로 배포하는 방식이다. 쉽게 설명하자면, 새로운 버전의 애플리케이션을 전체에 적용하기 전에 일부 파드에게만 먼저 적용해보고 문제가 없는지 확인한 후, 점진적으로 전체로 확장하는 방식이다.

장점 : 빠른 롤백이 가능하고 어플리케이션 성능 및 오류 모니터링에 용이하다.
단점 : 롤 아웃이 느리고 복잡한 트래픽 분산 설정이 필요하다.

3. 실습

3.1. 기본 Deployment

먼저 배포 전략을 지정하지 않은 기본 Deployment를 생성해보자. 참고로 별도의 strategy 항목을 지정하지 않으면 기본값은 RollingUpdate가 적용된다.

 

[1] Deployment 메니페스트 정의

deployment-strategy-01.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-strategy
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        project: deployment-strategy-01
        env: production
    spec:
      containers:
      - name: deployment-strategy-container
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

 

[2] 리소스 생성 및 스케일 확인

kubectl apply -f deployment-strategy-01.yaml
kubectl describe deployment/deployment-strategy

 

[3] 스케일 변경

kubectl scale deployment/deployment-strategy --replicas=5
kubectl get pods

3.2. Recreate 전략

[1] Deployment 메니페스트 수정

deployment-strategy-01.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-strategy
  labels:
    app: web
spec: 
  replicas: 3
  selector: 
    matchLabels: 
      app: web
  strategy:	# ✅ 배포 전략 설정
    type: Recreate # ✅ 모든 기존 파드를 제거 후 새로 생성
  template:
    metadata:
      labels:
        app: web
        project: deployment-strategy-01
        env: production
    spec:
      containers:
      - name: deployment-strategy-container
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

 

[2] 변경사항 적용

kubectl apply -f deployment-strategy-01.yaml

 

3.3. Rolling Update 전략

RollingUpdate는 기본 배포 전략으로, 기존 파드를 점진적으로 종료하고 새로운 파드를 순차적으로 배포하는 방식이다. maxUnavailable과 maxSurge 값을 통해 세부 설정이 가능하다. 

🧠 비유로 이해하기:
1. 회사에 컴퓨터가 4개 있는데, 최신 컴퓨터로 교체하려고 함
2. 4대의 컴퓨터를 한번에 교체하려고 종료하면 업무가 중단된다.(Recreate)
3. 그래서 하나씩 바꿔가면서 새로운 PC로 교체한다. (RollingUpdate)
    ㄴ maxUnavailable: 동시에 꺼도 되는 컴퓨터 수
    ㄴ maxSurge: 예비 컴퓨터 추가 설치 수

 

[1] Deployment 메니페스트 수정 (RollingUpdate 전략 적용)

vi deployment-strategy-01.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-strategy
  labels:
    app: web
spec: 
  replicas: 4
  selector: 
    matchLabels: 
      app: web
  strategy:	# ✅ 배포 전략 설정
    type: RollingUpdate	# ✅ RollingUpdate 전략
    rollingUpdate:	# ✅ 세부 설정
      maxUnavailable: 1	 # ✅ 동시에 종료 가능한 최대 파드 수
      maxSurge: 1	 # ✅ 동시에 새로 생성 가능한 최대 파드 수
  template:
    metadata:
      labels:
        app: web
        project: deployment-strategy-01
        env: production
    spec:
      containers:
      - name: deployment-strategy-container
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

 

[2] 변경사항 적용

# 변경사항 적용
kubectl apply -f deployment-strategy-01.yaml

3.4. Rollout 전략 적용 (버전 관리 & 롤백)

Rollout은 RollingUpdate 전략 위에서 버전 변경 이력 관리 및 롤백 기능을 활용하는 방식이다. Deployment에 변경 이력을 annotation으로 남기고, 필요 시 원하는 시점으로 되돌릴 수 있다.

 

[1] Deployment 메니페스트 수정 (Rollout 어노테이션 작성)

vi deployment-strategy-01.yaml
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: deployment-strategy
  labels: 
    app: web
  annotaions:
    "kubernetes.io/change-cause": "nginx image v1.25" # ✅ 변경 사유 기록
spec: 
  replicas: 4 # 
  selector: 
    matchLabels: 
      app: web
  strategy:	
    type: RollingUpdate
    rollingUpdate:	
      maxUnavailable: 1
      maxSurge: 1	
  template: 
    metadata: 
      labels: 
        app: web
        project: deployment-strategy-01
        env: production 
    spec: 
      containers:         
      - name: deployment-strategy-container
        image: nginx:1.25
        ports: 
        - containerPort: 80 
        resources: 
          limits: 
            memory: "64Mi" 
            cpu: "50m"

 

[2] 배포 리소스 생성 및 상태 확인

kubectl apply -f deployment-strategy-01.yaml
kubectl rollout status deployment/deployment-strategy

 

[3] 이미지 버전 변경

kubectl set image deployment/deployment-strategy web=nginx:1.26
kubectl get deployment -o wide

 

[4] 변경 사유 추가

kubectl annotate deployment/deployment-strategy kubernetes.io/change-cause="update nginx image to v1.26"

 

[5] 이전 배포 이력 확인 및 롤백

kubectl rollout history deployment/deployment-strategy
kubectl rollout history deployment/deployment-strategy --revision=2

# 특정 리비전으로 롤백
kubectl rollout undo deployment/deployment-strategy --to-revision=1

 

[6] 롤백 후 변경 사유 다시 기록

kubectl annotate deployment/deployment-strategy kubernetes.io/change-cause="rollback image version updated to v1.25 for settings"
kubectl rollout history deployment/deployment-strategy

3.5. Blue / Green 전략 적용

Blue/Green Deployment는 두 개의 독립된 환경(Blue와 Green)을 구성하여, 새로운 버전을 Green에 배포한 뒤, 트래픽을 한 번에 전환하는 방식이다. 롤백이 쉽고 배포가 명확하다는 장점이 있지만, 리소스를 이중으로 사용해야 한다는 단점이 있다.

3.5.1. Blue 버전 배포

[1] Blue 버전의 Deployment 메니페스트 정의

vi deployment-strategy-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-blue
  labels:
    app: web
    version: blue           # ✅ Blue 버전 라벨
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
      version: blue         # ✅ 서비스 선택자와 연결
  template:
    metadata:
      labels:
        app: web
        project: deployment-strategy-blue
        env: production
        version: blue       # ✅ 서비스 연결용 라벨
    spec:
      containers:
      - name: deployment-strategy-container-blue
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

 

3.5.2. Green 버전 배포

[1] Green 버전의 Deployment 메니페스트 정의

vi deployment-strategy-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-green
  labels:
    app: web
    version: green          # ✅ Green 버전 라벨
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
      version: green        # ✅ 서비스 전환 시 사용될 라벨
  template:
    metadata:
      labels:
        app: web
        project: deployment-strategy-green
        env: production
        version: green
    spec:
      containers:
      - name: deployment-strategy-container-green
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "64Mi"
            cpu: "50m"

 

3.5.3. 서비스 정의 (초기에는 Blue Deployment와 연결)

vi strategy-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: strategy-service
spec:
  selector:
    app: web
    version: blue           # ✅ 초기 연결 대상은 Blue
  ports:
  - port: 80
    targetPort: 80

 

3.5.4. 배포 및 트래픽 전환

[1] Blue 배포 및 서비스 연결

kubectl apply -f strategy-service.yaml
kubectl apply -f deployment-strategy-blue.yaml

 

[2] Green 배포

kubectl apply -f deployment-strategy-green.yaml
kubectl rollout status deployment/deployment-green

 

[3] 트래픽 전환 (Blue → Green)

kubectl patch service strategy-service -p '{"spec":{"selector":{"app":"web","version":"green"}}}'

 

3.5.5. 자동 배포 스크립트 예제

vi blue-green-strategy-autodeploy.sh
#!/bin/bash

# 1. Green 배포
kubectl apply -f deployment-strategy-green.yaml
kubectl rollout status deployment/deployment-green --timeout=120s

# 2. Green 배포 성공 시
if [ $? -eq 0 ]; then
  echo "✅ Green Deploy Success"

  # 서비스 트래픽 Green으로 전환
  kubectl patch service strategy-service -p '{"spec":{"selector":{"app":"web","version":"green"}}}'
  echo "✅ Traffic changed to Green"

  # 기존 Blue 제거
  kubectl delete deployment deployment-blue
  echo "✅ Blue Deploy Deleted"

# 3. 실패 시 롤백
else
  echo "❌ Green Deploy Failed. Rolling back to Blue"

  if kubectl get deployment deployment-blue > /dev/null 2>&1; then
    kubectl patch service strategy-service -p '{"spec":{"selector":{"app":"web","version":"blue"}}}'
    echo "✅ Traffic reverted to Blue"
  else
    echo "⚠️ Blue Deployment Not Found. Recreating..."
    kubectl apply -f deployment-strategy-blue.yaml
    kubectl patch service strategy-service -p '{"spec":{"selector":{"app":"web","version":"blue"}}}'
    echo "✅ Blue Redeployed and Traffic Reverted"
  fi

  # 실패한 Green 삭제
  kubectl delete deployment deployment-green
fi

 

 

 

 

 

 

 

'Kubernetes > Ops' 카테고리의 다른 글

[17] Helm  (0) 2025.06.17
[16] Kubernetes Autoscailing  (0) 2025.06.17
[14] Kubernetes Scheduler  (0) 2025.06.16
[13] Kubernetes Security  (5) 2025.06.14
[2] Kubernetes 환경 구축  (0) 2025.06.12

티스토리툴바