Introduction

사용자는 애플리케이션을 항상 사용할 수 있기를 기대하고 개발자는 하루에 여러 번 애플리케이션의 새 버전을 배포하는 상황이 필요하다.

이를 Kubernetes에서는 롤링 업데이트를 통해 무중단 배포를 수행할 수 있다.
롤링 업데이트를 사용 하면 Pod 인스턴스를 새 인스턴스로 점진적으로 업데이트하여 가동 중지 시간 없이 배포 업데이트를 수행할 수 있다.

maxSurge와 maxUnavailable란?

maxSurge와 maxUnavailable는 롤링 업데이트를 수행할 때 사용되는 중요한 매개변수 이다.

• maxUnavailable : 업데이트 중에 사용할 수 없는 최대 Pod 수
• maxSurge : 업데이트 중에 생성할 수 있는 추가적인 Pod 수

기본적으로 maxUnavailable 와 maxSurge는 모두 1로 설정되어 있고, 두 옵션 모두 숫자 또는 백분율로 구성할 수 있다.

---

각 옵션에 따른 전략

🎈 아래 예시의 replicas는 5로 고정된 상태를 가정한다.

maxSurge: 1 / maxUnavailable: 0

maxSurge =1(또는 n), maxUnavailable=0으로 설정한 경우

maxUnavailable 값이 0이기 때문에 업데이트 중에도 항상 최소 5개(replicas)의 동작하는 파드를 유지해야 한다.
따라서, 이전 버전의 Pod가 종료되기 위해서는 정상 동작하고 있는 파드의 수가 replicas 수 이상 일 때 종료할 수 있다.

• 장점
  • 새로운 Pod가 생성되어야 기존 Pod가 삭제되므로 안정적이다.
  • 새로운 버전의 파드를 많이 생성할 수 있으므로, 업데이트가 더 빨리 진행된다.
• 단점
  • 업데이트시 기존 replicas보다 많은 Pod가 생성되는 순간이 있기 때문에 리소스와 노드의 허용 Pod 수를 고려할 필요가 있다.
  • 리소스의 사용량이 많다.

---

maxSurge: 0 / maxUnavailable: 1

maxSurge=0, maxUnavailable=1(또는 n)으로 설정한 경우

maxSurge 값이 0이기 때문에 업데이트 중에 추가적인 새 파드를 생성할 수 없다.
따라서, maxUnavailable 를 통해서 기존 버전의 Pod가 완전히 종료된 후에 새로운 버전의 Pod가 생성할 수 있다.

• 장점
  • 설정된 replicas의 수를 넘지 않으므로, 리소스와 노드의 허용 Pod수를 고려하지 않아도 된다.
  • replicas 범위 내 파드만 생성/삭제하므로 리소스의 사용량이 적다.
• 단점
  • maxUnavailable의 값이 커지면 서비스의 중단 위험이 커질 수 있다.
  • 삭제되기 까지 새로운 파드를 미리 생성할 수 없어, 업데이트 속도가 느리다.

---

maxSurge: 0 / maxUnavailable: 0

만약 둘 다 0이 되는 경우는 어떨까?

사용할 수 없는 파드로 만들 수도 없고(이 경우 항상 replicas 개수를 유지해야 하므로 파드를 종료 못함), 파드를 추가적으로 생성할 수도 없으므로 RollingUpdate가 불가능하다.

---

업데이트 버전 관리

Kubernetes에서는 업데이트 버전이 관리되며 모든 배포 업데이트를 이전 버전으로 되돌릴 수 있다.

이제 실습을 진행해 보도록 하자.

• 실습에서는 strategy field를 따로 지정하지 않았으므로 기본값인 maxSurge : 1, maxUnavailable : 1 이 적용된다.

• 또한 모든 명령어에는 --record Flag를 지정해서 변경 사유(CHANGE-CAUSE)를 기록한다.
  --record Flag에 대해서 자세히 알고 싶다면 다음 글을 참고하라.

  issue Review - record 플래그의 Deprecate

실습

먼저 replicaset의 변화 확인을 위해 새 터미널에서 watch 옵션을 키고 진행한다.

watch "kubectl get replicasets.apps"

0. 디플로이먼트 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-rollout
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deploy-rollout
  template:
    metadata:
      labels:
        app: deploy-rollout
    spec:
      containers:
      - name: nginx
        # 시작 버전은 1.20.1
        image: nginx:1.20.1

디플로이먼트에 한개의 레플리카 셋이 있고 총 3개의 파드가 배포된 것을 확인할 수 있다.

• NAME: 디플로이먼트의 이름
• DESIRED: 원하는 레플리카의 수
• CURRENT: 현재 실행 중인 레플리카의 수
• READY: 사용 가능한(준비된) 레플리카의 수

1. 롤링 업데이트를 사용한 버전 업데이트

nginx:1.21.0 버전으로 업데이트를 수행해 보자.
set image 명령어를 통해서 롤링 업데이트를 수행 할 수 있다.

k set image deployment deploy-rollout nginx=nginx:1.21.0 --record

2. 없는 버전으로 업데이트

nginx:1.21.99 라는 없는 버전으로 업데이트를 수행해 보자.

3. 해당 업데이트 취소 (rollout)

잘못된 업데이트를 수행하였으므로 이전 상태로 돌아가야 한다.
rollout history 명령어를 통해서 기록을 확인하고, rollout undo를 통해서 업데이트를 취소 할 수 있다.

# 업데이트 기록 확인
k rollout history deployment deploy-rollout
# 롤 아웃 수행
k rollout undo deployment deploy-rollout

k rollout undo deployment deploy-rollout 명령을 사용하면 가장 최근의 변경 사항이 취소(REVISION : 3)되고 이전 버전(REVISION : 2)으로 롤백된다.

4. 제일 처음 버전으로 업데이트

--to-revision=<REVISON 번호> 를 통해서 이전 롤링 업데이트로 선택해서 돌아갈 수 있다.

원래는 제일 처음 배포한 버전이므로 첫 버전은 REVISION 1번에 위치해야 정상이지만, 이것 저것 실습하다가 REVISION 5번에 위치하고 있다.

# 업데이트 기록 확인
k rollout history deployment deploy-rollout
# 처음 버전으로 업데이트
k rollout undo deployment deploy-rollout --to-revision=5

Reference

• 롤링 업데이트 - 공식문서
• Kubernetes Rolling Update