[MacOS 환경 #25] 쿠버네티스 롤링 업데이트(RollingUpdate)

도람·2025년 11월 28일

RollingUpdate 쿠버네티스

🖥️제로부터 시작하는 Docker & 쿠버네티스

목록 보기

54/82

롤링 업데이트(RollingUpdate)란?

롤링 업데이트란 쿠버네티스에서 Deployment/StatefulSet의 기본 업데이트 전략이 롤링 업데이트이다.

공식 문서 기준으로 보면 롤링 업데이트는

기존 파드를 한 번에 전부 죽이지 않고,
새 버전 파드를 조금씩 띄우고, 옛날 파드를 조금씩 내리면서
서비스 중단 없이 버전을 교체하는 전략

이라고 정리할 수 있다.

컨트롤 플레인은 다음 순서로 동작한다.

새 템플릿(예: 이미지 버전 변경)으로 ReplicaSet을 하나 더 만든다.
새 ReplicaSet 파드를 조금 늘리고(maxSurge),
옛 ReplicaSet 파드를 조금 줄인다(maxUnavailable).
원하는 개수(Replicas)만큼 전부 새 버전으로 바뀔 때까지 2번을 반복한다.

그래서:

서비스 트래픽을 받는 파드 수는 항상 일정 수준 이상 유지되고
사용자는 “업데이트 중”인 상태를 거의 못 느끼게 된다.
반대로 새 버전이 문제 있으면 롤백(rollout undo) 로 이전 버전으로 되돌릴 수 있다.

Deployment YAML 에서 전략은 이렇게 정의된다.

spec:
  strategy:
    type: RollingUpdate        # 기본값
    rollingUpdate:
      maxSurge: 1              # 원하는 replicas 수보다 임시로 1개 더 많이 띄워도 됨
      maxUnavailable: 0        # 업데이트 중에 죽어도 되는 파드 수 (0이면 항상 다 살아 있어야 함)

왜 기본값이 RollingUpdate일까

Recreate 전략은 기존 파드를 한 번에 다 죽였다가 새로 올리는 방식이라,
짧은 시간이라도 서비스가 완전히 끊길 수 있다.

대부분의 웹 서비스는 “무중단 배포”가 중요해서,
쿠버네티스가 기본 전략을 RollingUpdate 로 정해 둔 것이다.

실습 시나리오 개요

nginx 를 예제로 해서 아래 흐름으로 연습해볼 것이다.

v1.20.1 버전으로 Deployment 생성 (replicas=3)
이미지를 v1.21.0 으로 업데이트 → 롤링 업데이트 동작 확인
일부러 이상한 버전(예: nginx:1.21.21)으로 바꿔서 실패시키기
kubectl rollout undo / --to-revision 으로 롤백 연습

실습

1. 기본 Deployment 생성

파일명: nginx-rollout-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-rollout
  labels:
    app: nginx-rollout
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 업데이트 중에 임시로 1개 더 생성 가능
      maxUnavailable: 0    # 항상 3개 다 살아 있도록
  selector:
    matchLabels:
      app: nginx-rollout
  template:
    metadata:
      labels:
        app: nginx-rollout
    spec:
      containers:
      - name: nginx
        image: nginx:1.20.1      # ① 시작 버전
        ports:
        - containerPort: 80

적용&확인

# Deployment 생성
kubectl apply -f nginx-rollout-deploy.yaml

# 파드 확인
kubectl get deploy nginx-rollout
kubectl get pods -l app=nginx-rollout -o wide

이렇게 deployment로 배포한 파드 3개가 Running으로 잘 배포된 것을 확인할 수 있다.

2. 1차 롤링 업데이트 – 1.20.1 → 1.21.0

1) 이미지 버전 변경

Deployment 의 컨테이너 이미지만 바꾸면 된다.
공식 문서에서도 kubectl set image 로 예제를 많이 보여준다.

kubectl set image deploy/nginx-rollout \
  nginx=nginx:1.21.0

이 명령 한 줄로 Deployment 템플릿이 바뀌었고,
컨트롤 플레인이 롤링 업데이트를 시작한다

2) 롤링 진행 상황 확인

# 롤아웃 상태 모니터링
kubectl rollout status deploy/nginx-rollout

# 파드/ReplicaSet 확인
kubectl get rs -l app=nginx-rollout
kubectl get pods -l app=nginx-rollout -o wide

이렇게 버전 업 한 후, kubectl rollout status deploy/nginx-rollout를 하여
모니터링 하면 롤아웃이 되는 것을 확인할 수 있다.

또한

새 ReplicaSet(1.21.0) 파드가 1개 뜨고
옛 ReplicaSet(1.20.1) 파드가 1개 내려가고
다시 새 파드 1개 뜨고, 옛 파드 1개 내려가고…

이런 식으로 한 번에 일부만 교체되는 걸 볼 수 있다.

3) 2차 롤링 업데이트 – 실패하는 버전으로 바꾸기

이번엔 일부러 말도 안 되는 태그를 써서 실패 상황을 만든다.

kubectl set image deploy/nginx-rollout \
  nginx=nginx:1.21.21

상태확인 명령어

kubectl get pods -l app=nginx-rollout
kubectl describe deploy nginx-rollout
kubectl rollout status deploy/nginx-rollout

이렇게 상태확인 명령어를 쳐서 상태를 확인해보면,

이미지가 존재하지 않으면 새 파드가 ImagePullBackOff 나 ErrImagePull 상태가 되면서,
롤링 업데이트가 중간에서 멈추거나 실패 상태가 되는 것을 확인할 수 있다.

3. 롤링 업데이트 롤백(rollback)

1) 바로 이전 버전으로 롤백

kubectl rollout undo deploy/nginx-rollout

이렇게 하면 직전 리비전(바로 전에 쓰던 템플릿)으로 되돌린다.
지금 케이스에서는 다시 nginx:1.21.0 으로 돌아가게 된다.

상태확인 명령어

kubectl get pods -l app=nginx-rollout
kubectl describe deploy nginx-rollout | grep Image

이렇게 버전이 다시 바뀐것을 확인할 수 있다.

2) 리비전 목록 확인 + 특정 리비전으로 롤백

Deployment 는 변경될 때마다 “리비전(Revision)” 이라는 번호를 붙여서 기록한다.

# 히스토리 확인
kubectl rollout history deploy/nginx-rollout

# 특정 리비전 상세 보기
kubectl rollout history deploy/nginx-rollout --revision=1

예를 들어,

revision 1: nginx:1.20.1
revision 2: nginx:1.21.0
revision 3: nginx:1.21.21 (실패 버전)

이라고 되어 있다면, 1번 리비전으로 완전히 되돌리고 싶을 때:

kubectl rollout undo deploy/nginx-rollout --to-revision=1

하면 1번 리비전으로 되돌릴 수 있다.

상태 확인 명령어

kubectl describe deploy nginx-rollout | grep Image
kubectl get pods -l app=nginx-rollout

그러면 이렇게 1번 리비전으로 가게 되면서,
kubectl describe deploy nginx-rollout | grep Image 명령어를 실행하면

history에서 1번 리비전인 상태밖에 남지 않게 된다.

정리

전략 타입	동작 방식	장단점 요약
RollingUpdate	새 파드 ↑, 옛 파드 ↓ 를 조금씩 반복하며 교체	무중단에 가까움, 기본값
Recreate	기존 파드 전부 삭제 후 새 파드 전부 생성	배포 중 완전 중단, 대신 구현은 단순함

롤링 업데이트는 서비스 중단 없이 파드를 점진적으로 교체하는 기본 업데이트 전략이다.
maxSurge, maxUnavailable 값으로
“업데이트 중에 최대 몇 개까지 더 띄워도 되고 / 죽어도 되는지”를 조절한다.
kubectl set image, kubectl rollout status, kubectl rollout history,
kubectl rollout undo 조합으로
- 새 버전 배포
- 실패한 배포 감지
- 특정 리비전으로 롤백
  전부 다 컨트롤할 수 있다.

참고 자료:
[쿠버네티스 공식 홈페이지 - kubectl rollout]
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_rollout/
[쿠버네티스 공식 홈페이지 - Performing a Rolling Update]
https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/