Kubernetes 롤링 업데이트 이해

1. 문제 / 필요성

Deployment로 상태를 유지할 수는 있다. 하지만 운영에서 더 중요한 순간은 “변경”이다.

• 이미지 버전을 변경해야 하는 경우
• 설정을 수정해야 하는 경우
• 애플리케이션을 업데이트해야 하는 경우

이때 단순하게 Pod을 모두 교체하면 문제가 발생한다.

• 기존 Pod가 모두 종료되는 순간 서비스 중단 발생
• 새 버전에 문제가 있으면 전체 서비스 장애
• 정상 여부 확인 없이 한 번에 반영됨

필요한 것은 하나다.

“서비스를 유지하면서 상태를 교체하는 방식”

---

2. 롤링 업데이트란 무엇인가

롤링 업데이트는 기존 Pod을 유지한 상태에서, 새로운 Pod으로 점진적으로 교체하는 방식이다.

한 번에 바꾸는 것이 아니라, “조금씩 바꾼다”

---

3. 기본 동작 구조

Deployment는 내부적으로 ReplicaSet을 사용한다. 업데이트가 발생하면 구조는 다음처럼 바뀐다.

Deployment
 ├─ ReplicaSet (old)
 └─ ReplicaSet (new)

deployment 업데이트 진행시 기존에 있던 ReplicaSet과 교체되는 것을 확인할 수 있다.

• 기존 ReplicaSet → 기존 Pod 관리
• 새로운 ReplicaSet → 새로운 Pod 생성

두 개가 동시에 존재하면서 교체가 진행된다.

---

4. 롤링 업데이트 동작 흐름

[출처]: https://nearhome.tistory.com/106

Replicasets:
    Desired: Pod 3개
    기존 버전: hello-server-6cc6b44795
    변경 버전: hello-server-5d6fd6dbb9

 

단계별 흐름

“새로운 Pod을 먼저 띄우고, 정상 확인 후 기존 Pod을 제거한다”

---

5. 핵심 제어 옵션

롤링 업데이트는 두 값으로 제어된다.

5.1 maxSurge

업데이트 중 추가로 생성할 수 있는 Pod 수

maxSurge: 1

 

• 원래 3개 → 최대 4개까지 생성 가능

새 Pod을 먼저 생성할 수 있게 해준다

5.2 maxUnavailable

업데이트 중 사용 불가능해도 되는 Pod 수

maxUnavailable: 0

 

• 항상 최소 3개 유지

서비스 중단 방지 역할

예시 설정

replicas: 3
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

 

의미:

• 최대 4개까지 Pod 생성 가능
• 항상 최소 3개는 정상 상태 유지

---

6. Readiness Probe와의 관계

Readiness Probe란 무엇인가

Readiness Probe는 해당 Pod가 “서비스 요청을 받아도 되는 상태인지”를 판단하는 기준이다.

왜 필요한가

컨테이너는 “실행 중(Running)” 상태라고 해서 바로 요청을 받을 수 있는 상태는 아니다.

예를 들어

• 서버는 켜졌지만 DB 연결 아직 안 됨
• 애플리케이션 초기화 진행 중
• 캐시 로딩 중

이 상태에서 트래픽을 보내면 오류가 발생한다.

롤링 업데이트에서 중요한 기준은 단순 “생성”이 아니다.“서비스 가능 상태인지”

 

새로운 Pod가 생성되더라도 readinessProbe를 통과해야 트래픽을 받는다.

동작 기준

Pod 생성됨 ≠ 서비스 가능
Readiness 통과 = 서비스 가능

 

이 구조 덕분에

• 준비되지 않은 Pod으로 트래픽 전달 방지
• 안정적인 교체 가능

---

7. 실패 시 동작

새로운 Pod이 정상 상태가 되지 못하면:

• 기존 Pod 유지
• 업데이트 중단

실패 원인 예시

• 이미지 오류
• 환경 변수 문제
• 애플리케이션 실행 실패
• readinessProbe 실패

“정상 상태가 확인되지 않으면 교체하지 않는다”

---

8. 롤백이 가능한 이유

Deployment는 업데이트 시 새로운 ReplicaSet을 생성한다.

Deployment
 ├─ ReplicaSet v1
 └─ ReplicaSet v2
 └─ ReplicaSet v3

 

이전 ReplicaSet이 남아 있기 때문에 문제 발생 시 되돌릴 수 있다.

롤백 명령

바로 직전 Replicasets으로 롤백

kubectl rollout undo deployment <deployment-name>

“이전 상태를 기억하고 있기 때문에 복구 가능”

 

특정 revision을 지정해서 롤백

1. 먼저 revision 확인

kubectl rollout history deployment hello-server

 

출력 예:

deployment.apps/hello-server
REVISION  CHANGE-CAUSE
1         nginx:1.25
2         nginx:1.26
3         nginx:1.27

여기서 숫자가 revision이다.

 

2. 특정 revision으로 롤백

kubectl rollout undo deployment hello-server --to-revision=2

 

결과

• revision 2 상태로 되돌아감
• 해당 ReplicaSet이 다시 활성화됨

3. 내부에서 실제로 일어나는 일

롤백은 “시간을 되돌리는 것”이 아니다.

구조는 이렇게 바뀐다.

Deployment
 ├─ ReplicaSet v1
 ├─ ReplicaSet v2 ← 롤백 대상
 └─ ReplicaSet v3

 

→ v2 ReplicaSet을 다시 scale up
→ 현재 ReplicaSet을 scale down

---

9. 전체 구조

롤링 업데이트는 다음 흐름으로 동작한다.

• Deployment → 상태 변경 감지
• Controller → 새로운 ReplicaSet 생성
• 새 Pod 생성
• 상태 확인
• 기존 Pod 제거

“상태를 유지한 채 새로운 상태로 점진적으로 이동”

---

10. 핵심 정리

• 롤링 업데이트는 Pod을 한 번에 교체하지 않는다
• 새로운 Pod을 먼저 생성하고 정상 상태를 확인한다
• 기존 Pod을 점진적으로 제거한다
• maxSurge / maxUnavailable로 교체 속도 조절
• readinessProbe로 서비스 안정성 보장
• ReplicaSet 구조로 롤백 가능

---

11. 회고

Deployment를 단순히 “Pod 개수를 유지하는 도구”로 보면 롤링 업데이트는 별도 기능처럼 보인다.

하지만 구조 기준으로 보면 다르다.

• Deployment는 상태를 정의하고
• Controller는 상태를 유지하며
• 롤링 업데이트는 “상태 변경 방식”이다

Kubernetes는 상태를 유지하는 것뿐만 아니라 상태를 바꾸는 과정까지 관리한다