🚀 무중단 배포의 마법, Kubernetes Deployment 롤링 업데이트!

안녕하세요! 👋 오늘은 쿠버네티스에서 가장 사랑받는 기능이자, 현대적인 CI/CD의 핵심인 Deployment의 애플리케이션 업데이트 전략에 대해 깊이 알아보겠습니다.

 

"서버 점검 중입니다."라는 공지를 띄우고 새벽에 작업하던 시대는 지났습니다. 이제 사용자들은 24시간 내내 중단 없는 서비스를 기대하죠. 쿠버네티스의 롤링 업데이트(Rolling Update)는 바로 이러한 요구를 충족시켜주는, 서비스 중단 없이 안전하게 애플리케이션을 새로운 버전으로 배포하는 마법 같은 기능입니다.

 

---

🤔 롤링 업데이트(Rolling Update)란 무엇일까요?

롤링 업데이트는 마치 고속도로의 차선을 하나씩 점진적으로 재포장하는 것과 같습니다. 전체 도로를 막는 대신, 일부 차선만 통제하여 차량 흐름(서비스 트래픽)을 유지하면서 공사를 진행하는 방식이죠.

쿠버네티스에서는 이 원리를 파드(Pod)에 적용합니다.

 

롤링 업데이트의 원리:

1. 새 버전 파드 생성: 먼저 새로운 버전의 애플리케이션 이미지를 가진 파드(v2)를 하나 생성합니다.
2. 새 파드 준비 확인: 새로 만든 v2 파드가 정상적으로 실행되고, 트래픽을 받을 준비가 될 때까지 기다립니다.
3. 구 버전 파드 삭제: v2 파드가 준비되면, 기존 버전의 파드(v1)를 하나 삭제합니다.
4. 반복: 이 과정을 모든 구 버전(v1) 파드가 새로운 버전(v2) 파드로 교체될 때까지 반복합니다.

이러한 점진적인 교체 방식 덕분에, 업데이트가 진행되는 동안에도 항상 일정 수 이상의 파드가 사용자 요청을 처리하므로 서비스 중단 시간(Downtime)이 발생하지 않습니다. ✨

---

🚀 애플리케이션 신규 버전 배포 실습

자, 이제 직접 디플로이먼트를 새로운 버전으로 업데이트해 봅시다.

1. 초기 버전(v1) 배포

먼저, nginx:1.22.1 버전을 사용하는 디플로이먼트를 3개의 복제본(replicas)으로 배포합니다.

 

my-app-v1.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.22.1 # 초기 버전
        ports:
        - containerPort: 80

 

kubectl apply -f my-app-v1.yaml

 

2. 신규 버전(v2)으로 업데이트

이제 nginx 버전을 1.23.4로 업그레이드해 보겠습니다. 우리가 할 일은 정말 간단합니다. YAML 파일의 이미지 태그만 수정하면 됩니다!

 

my-app-v2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.23.4 # <<<--- 여기만 신규 버전으로 변경!
        ports:
        - containerPort: 80

 

그리고 똑같은 apply 명령어를 다시 실행합니다.

kubectl apply -f my-app-v2.yaml

 

3. 업데이트 과정 지켜보기

apply 명령을 실행하는 순간, 디플로이먼트 컨트롤러는 변경 사항을 감지하고 롤링 업데이트를 시작합니다. 이 마법 같은 과정을 직접 눈으로 확인할 수 있습니다.

 

업데이트 상태 실시간 확인:

# deployment/my-app의 롤아웃 상태를 지켜봅니다.
kubectl rollout status deployment/my-app

 

파드가 교체되는 과정 실시간 확인 (별도의 터미널에서 실행):

# 파드 목록을 2초마다 갱신하며 보여줍니다.
watch -n 2 kubectl get pods

 

잠시 지켜보면, 새로운 pod-template-hash를 가진 파드들이 하나씩 Running 상태가 되고, 기존 파드들은 Terminating 상태가 되며 사라지는 것을 볼 수 있습니다. 모든 과정이 끝나면 모든 파드가 새로운 이미지 버전으로 교체되어 있습니다!

---

⚙️ 롤링 업데이트 세부 설정: strategy

디플로이먼트는 롤링 업데이트의 속도와 안정성을 조절할 수 있는 두 가지 중요한 옵션을 제공합니다. 바로 maxSurge와 maxUnavailable입니다.

...
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 업데이트 중 replicas 개수를 초과하여 생성할 수 있는 최대 파드 수
      maxUnavailable: 0  # 업데이트 중 사용 불가능 상태가 될 수 있는 최대 파드 수
...

• maxSurge (최대 초과): 업데이트 중에 replicas 개수를 초과하여 일시적으로 더 존재할 수 있는 파드의 최대 개수입니다.
  • 예시: replicas: 3, maxSurge: 1 이면, 업데이트 중에 파드의 총개수는 최대 4개까지 늘어날 수 있습니다. (새 버전 파드를 먼저 띄우고 구 버전을 삭제)
  • 값을 높이면 업데이트 속도가 빨라지지만, 순간적으로 더 많은 리소스를 사용합니다.
• maxUnavailable (최대 비활성): 업데이트 중에 사용 불가능한 상태가 될 수 있는 파드의 최대 개수입니다.
  • 예시: replicas: 3, maxUnavailable: 1 이면, 업데이트 중에도 최소 2개의 파드는 항상 정상적으로 요청을 처리하도록 보장합니다.
  • 값을 낮추면 안정성은 높아지지만, 업데이트 속도는 느려집니다. 0으로 설정하면 무조건 maxSurge 만큼 파드를 먼저 띄워야 하므로 서비스 안정성을 극대화할 수 있습니다.
• 값은 정수(예: 1, 2) 또는 퍼센트(예: "25%")로 지정할 수 있습니다.

---

⏪ 롤백: 잘못되면 되돌리기

만약 새로운 버전에 심각한 버그가 발견되면 어떻게 할까요? 걱정 마세요. 디플로이먼트는 업데이트 기록을 모두 기억하고 있어, 단 한 줄의 명령어로 이전 버전으로 되돌릴 수 있습니다.

Bash

 

# 이전 버전으로 롤백 실행
kubectl rollout undo deployment/my-app

이 명령어를 실행하면, 롤링 업데이트와 동일한 방식으로 안전하게 이전 버전으로 롤백이 진행됩니다.

---

✅ 정리하며

Deployment의 롤링 업데이트는 쿠버네티스가 제공하는 가장 강력하고 필수적인 기능 중 하나입니다.

• 무중단 배포: 사용자는 서비스 중단을 전혀 느끼지 못합니다.
• 선언적 관리: YAML 파일에 원하는 상태만 선언하면 쿠버네티스가 알아서 처리합니다.
• 안정성 제어: maxSurge, maxUnavailable 옵션으로 업데이트의 속도와 안정성을 자유롭게 조절할 수 있습니다.
• 간편한 롤백: 문제가 발생했을 때 즉시 이전 버전으로 돌아갈 수 있는 안전망을 제공합니다.

이제 여러분도 롤링 업데이트를 통해 더 안정적이고 유연한 애플리케이션 배포 파이프라인을 구축해 보세요!