[kubernetes] 쿠버네티스 배포 전략 완벽 가이드: 롤링 업데이트부터 카나리 배포까지

이번 주제는 쿠버네티스 환경에서 애플리케이션을 중단 없이 안정적으로 배포하는 다양한 전략들에 대해 심도 있게 알아보려 합니다. 특히 가장 흔히 사용되는 **롤링 업데이트(Rolling Update)**를 중심으로, 다른 주요 배포 방식들과 비교하고 실제 동작 원리 및 테스트 결과까지 상세히 다뤄보겠습니다.

 

이전에 학습한 [k8s] 외부 접속은 왜 Ingress일까? 쿠버네티스 인/아웃바운드 트래픽 총정리 알아보기

 

---

1. 왜 배포 전략이 중요할까요?

현대의 마이크로서비스 아키텍처에서 애플리케이션은 빈번하게 업데이트됩니다. 새로운 기능 추가, 버그 수정, 성능 개선 등을 위해 새로운 버전의 컨테이너 이미지를 배포해야 하죠. 하지만 이 과정에서 서비스가 중단되거나(Downtime), 예상치 못한 오류로 인해 사용자 경험이 저하된다면 큰 문제입니다.

쿠버네티스는 이러한 문제를 해결하기 위해 다양한 **배포 전략(Deployment Strategies)**을 제공합니다. 적절한 전략을 선택하면 다음과 같은 이점을 얻을 수 있습니다.

• 제로 다운타임(Zero Downtime): 사용자에게 중단 없는 서비스를 제공하면서 업데이트를 진행합니다.
• 안정성 확보: 배포 과정에서 문제가 발생했을 때 빠르게 이전 버전으로 롤백(Rollback)할 수 있습니다.
• 리스크 감소: 카나리 배포 같은 전략을 통해 새로운 버전의 영향을 최소화하면서 검증할 수 있습니다.

이제 본격적으로 쿠버네티스의 기본 배포 전략인 롤링 업데이트부터 살펴보겠습니다.

---

2. 쿠버네티스 롤링 업데이트 (Rolling Update) 깊이 보기

롤링 업데이트는 쿠버네티스 Deployment 리소스의 기본 배포 전략입니다. 이름 그대로, 이전 버전의 포드(Pod)를 하나씩 점진적으로 새로운 버전의 포드로 교체하는 방식입니다. 이 과정을 통해 서비스 중단 없이 자연스럽게 업데이트가 완료됩니다.

동작 원리

롤링 업데이트의 핵심은 ReplicaSet을 활용하는 것입니다. 배포가 시작되면 쿠버네티스는 새로운 버전의 이미지를 가진 새로운 ReplicaSet을 생성합니다. 그리고 기존 ReplicaSet의 포드 수를 점진적으로 줄이면서, 동시에 새로운 ReplicaSet의 포드 수를 늘립니다. 이 과정을 '롤링(rolling)'한다고 표현합니다.

다음 아키텍처 다이어그램을 통해 롤링 업데이트의 흐름을 시각적으로 이해해 봅시다.

1. 초기 상태: 버전 1(V1) 포드 3개가 가동 중입니다. (ReplicaSet V1)
2. 업데이트 시작: 새로운 ReplicaSet V2가 생성됩니다. V2 포드가 1개 생성되고, 안정화되면 V1 포드 중 하나가 삭제됩니다.
3. 진행 중: V2 포드가 또 하나 생성되고, V1 포드가 또 하나 삭제됩니다. 트래픽은 V1과 V2 포드 모두로 로드밸런싱됩니다.
4. 완료: 모든 V1 포드가 삭제되고 V2 포드 3개만 남습니다. 업데이트가 성공적으로 완료되었습니다.

주요 설정 파라미터

Deployment 매니페스트에서 spec.strategy.rollingUpdate 필드를 통해 롤링 업데이트의 동작을 세밀하게 제어할 수 있습니다.

• maxSurge: 업데이트 과정에서 설정된 replicas 수를 초과하여 생성할 수 있는 포드의 최대 개수(또는 비율)입니다. 기본값은 25%입니다. 예를 들어 replicas: 4이고 maxSurge: 1이면, 업데이트 중에 순간적으로 최대 5개의 포드가 존재할 수 있습니다.
• maxUnavailable: 업데이트 과정에서 사용할 수 없는 상태가 될 수 있는 포드의 최대 개수(또는 비율)입니다. 기본값은 25%입니다. 예를 들어 replicas: 4이고 maxUnavailable: 1이면, 업데이트 중에 최소 3개의 포드는 항상 가동 상태를 유지해야 합니다.

이 두 파라미터를 적절히 조절하여 업데이트 속도와 리소스 가용성 사이의 균형을 맞출 수 있습니다.

실습 및 테스트 결과

이제 직접 롤링 업데이트를 수행하고 그 결과를 확인해 보겠습니다.

 

1) 초기 배포 (V1)

간단한 웹 애플리케이션(V1)을 배포하는 deployment.yaml 파일입니다.

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
        image: myregistry/my-app:v1
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: LoadBalancer

애플리케이션을 배포합니다.

Bash

kubectl apply -f deployment.yaml

 

2) 업데이트 실행 (V2)

이제 이미지를 V2로 업데이트합니다. kubectl set image 명령어를 사용하면 편리합니다.

Bash

kubectl set image deployment/my-app my-app=myregistry/my-app:v2

 

3) 업데이트 상태 확인 (Hands-on)

업데이트 진행 상황을 모니터링해 봅니다.

Bash

# 포드 상태 변화 모니터링
kubectl get pods -w

# 배포 상태 확인
kubectl rollout status deployment/my-app

# ReplicaSet 확인
kubectl get replicasets

 

테스트 결과 해석:

• kubectl get pods -w 출력을 보면 새 포드가 Pending -> ContainerCreating -> Running 상태로 바뀌는 동안 기존 포드가 Terminating 상태로 바뀌는 것을 볼 수 있습니다. maxSurge와 maxUnavailable 설정에 따라 동시에 진행되는 개수가 달라집니다.
• kubectl get replicasets 명령어를 실행하면, 업데이트 중에 두 개의 ReplicaSet(V1용, V2용)이 동시에 존재하며, 각각의 포드 수가 점진적으로 변하는 것을 확인할 수 있습니다.
• 서비스 배포 도중 외부에서 계속해서 트래픽을 보내보면, 중단 없이 V1 응답과 V2 응답이 번갈아 나오다가 결국 V2 응답만 나오게 되는 것을 확인할 수 있습니다. (제로 다운타임 검증)

4) 롤백 (Rollback)

만약 V2 배포 후 문제가 발견된다면, 이전 버전으로 빠르게 되돌릴 수 있습니다.

Bash

 

kubectl rollout undo deployment/my-app

쿠버네티스는 자동으로 이전 ReplicaSet의 포드 수를 늘리고 V2 ReplicaSet의 포드 수를 줄여 롤백을 수행합니다.

---

3. 다른 배포 전략들과의 비교

롤링 업데이트 외에도 상황에 따라 유용하게 사용할 수 있는 다른 배포 전략들이 있습니다. 대표적인 것들로는 Recreate, Blue/Green, Canary 배포가 있습니다.

Recreate 배포

가장 단순한 방식으로, 기존 버전의 모든 포드를 먼저 삭제한 후 새로운 버전의 포드를 한꺼번에 생성합니다.

• 장점: 구성이 매우 간단하며, 구버전과 신버전이 공존하는 기간이 없습니다. 데이터베이스 스키마 변경 등이 동반되어 두 버전이 공존할 수 없을 때 유용합니다.
• 단점: 기존 포드가 삭제되고 새 포드가 생성되어 실행될 때까지 **서비스 중단(Downtime)**이 발생합니다. 운영 환경에서는 거의 사용되지 않습니다.

Blue/Green 배포

쿠버네티스 기본 기능은 아니지만, 서비스를 활용하여 구현할 수 있는 강력한 방식입니다. 구버전(Blue) 환경을 그대로 두고, 완전히 새로운 버전(Green) 환경을 동일한 규모로 별도로 구축합니다. Green 환경의 검증이 완료되면, 서비스(로드밸런서)의 엔드포인트를 Blue에서 Green으로 한순간에 전환합니다.

• 장점: 서비스 전환이 즉시 이루어지므로 다운타임이 거의 없습니다. 문제가 발생하면 서비스 엔드포인트만 다시 Blue로 되돌리면 되므로 롤백이 매우 빠르고 안정적입니다.
• 단점: 일시적으로 두 배의 리소스가 필요하므로 비용 부담이 큽니다.

카나리(Canary) 배포

새로운 버전을 전체 사용자 중 일부에게만 먼저 배포하여 성능과 안정성을 검증하는 방식입니다. 초기에는 적은 수의 새 버전 포드를 배포하고, 모니터링 결과가 양호하면 점진적으로 새 버전의 비중을 높여 최종적으로 전체 배포를 완료합니다. 광산의 카나리아처럼 위험을 미리 감지한다는 의미입니다.

• 장점: 실제 운영 환경의 트래픽을 활용하여 새로운 버전을 안전하게 검증할 수 있습니다. 문제가 발생해도 영향도를 최소화할 수 있습니다.
• 단점: 배포 과정이 복잡하며, 정교한 트래픽 제어(Istio 같은 서비스 메쉬 활용 권장)와 모니터링 시스템이 필요합니다.

---

4. 핵심 정리 및 인사이트

지금까지 쿠버네티스의 롤링 업데이트와 다른 배포 전략들에 대해 알아보았습니다. 각 전략의 특징을 표로 정리해 보겠습니다.

배포 전략	다운타임	리소스 추가 필요	롤백 속도	복잡도	주요 용도
Rolling Update	없음 (제로 다운타임)	적음 (maxSurge 만큼)	보통	보통	운영 환경의 기본 배포 방식
Recreate	있음 (Downtime 발생)	없음	느림	낮음	개발/테스트 환경, 하위 호환성 없는 변경
Blue/Green	거의 없음 (즉시 전환)	많음 (2배 리소스)	매우 빠름	보통	리소스 여유가 있고 빠른 롤백이 중요할 때
Canary	없음 (제로 다운타임)	적음	빠름	높음	리스크 최소화하며 실제 트래픽 검증 필요시

 

 

결론 및 인사이트

쿠버네티스는 강력한 배포 기능을 내장하고 있어 제로 다운타임 배포를 손쉽게 구현할 수 있게 해줍니다. 롤링 업데이트는 대부분의 운영 환경에서 기본적으로 사용하기에 충분히 훌륭한 전략입니다. 특히 maxSurge와 maxUnavailable 값을 적절히 활용하면 업데이트 속도와 리소스 사용률을 최적화할 수 있습니다.

 

하지만 무조건 롤링 업데이트가 정답은 아닙니다. 데이터베이스 스키마 변경처럼 두 버전의 공존이 불가능한 경우엔 Recreate나 별도의 이관 전략이 필요할 수 있습니다. 또한, 배포 리스크가 크거나 매우 신속한 롤백이 요구되는 크리티컬한 서비스라면 리소스 비용을 감수하고서라도 Blue/Green 배포를 고려해 볼 만합니다. 최신 기능을 안전하게 검증하고 사용자 경험을 세밀하게 제어하고 싶다면 카나리 배포가 훌륭한 선택지가 될 수 있습니다. (이 경우 Istio, Linkerd 같은 서비스 메쉬를 병행하면 더욱 강력한 트래픽 제어가 가능해집니다.)

 

결국 완벽한 배포 전략이란 없습니다. 각 전략의 장단점을 명확히 이해하고, 여러분의 애플리케이션 특성, 인프라 리소스 상황, 조직의 운영 성숙도, 그리고 비즈니스 요구사항에 맞춰 가장 적합한 전략을 선택하고 구성하는 것이 중요합니다. 더 나아가 이러한 배포 과정을 CI/CD 파이프라인과 연동하여 자동화한다면, 더욱 빠르고 안정적인 소프트웨어 딜리버리가 가능해질 것입니다.