개요

Kubernetes의 Deployment 객체를 이용해 무중단 배포를 적용하는 방법을 정리했습니다.

Rolling Update

개념

Rolling Update는 Kubernetes에서 기본적으로 적용하는 업데이트 방식입니다. 이 배포 전략은 다음과 같이 진행됩니다.

기존 버전(v1) 파드 3개가 실행 중인 상태에서 새로운 버전(v2)을 배포한다고 가정해봅시다. 먼저 v2 파드 1개를 생성한 뒤 v1 파드 1개를 종료합니다. 이 과정을 반복하면서 점차 v2 파드로 전환합니다. 배포 중에는 트래픽이 v1과 v2로 랜덤하게 분산됩니다.

구현

Deployment 객체의 maxSurge 속성과 maxUnavailable 속성을 활용해 Rolling Update 전략을 세부적으로 설정할 수 있습니다.

• maxSurge: 업데이트 중 spec.replicas 에 설정된 파드 수를 기준으로 새로 생성할 수 있는 최대 파드 수를 지정합니다.
• maxUnavailable: 업데이트 중 spec.replicas 를 기준으로 사용 가능하지 않은 최대 파드 수를 지정합니다.

1. [새 파드 생성 - 기존 파드 삭제] 반복 전략

• 설명: 기존 파드를 종료하기 전에 새로운 파드를 먼저 생성합니다.
• 예시: 전체 파드 개수가 10개이고 maxSurge가 1로 설정된 경우, 업데이트 중 최대 11개의 파드가 존재할 수 있습니다. 새로운 버전(v2) 파드를 하나 생성한 뒤 기존 버전(v1) 파드를 하나씩 종료합니다.
• 필수 조건: 이 전략을 사용할 때 maxUnavailalbe은 0으로 설정해야 합니다.

그림으로 시각화하면 다음과 같습니다. (편의상 전체 파드의 개수는 3개로 설정)

2. [기존 파드 삭제 - 새 파드 생성] 반복 전략

• 설명: 기존 파드를 종료한 뒤 새로운 파드를 생성합니다.
• 예시: 전체 파드 개수가 10개이고 maxUnavailable가 1로 설정된 경우, 업데이트 중 파드 수는 최대 9개로 줄어들 수 있습니다. 기존 버전(v1) 파드를 하나 종료한 뒤 새로운 버전(v2) 파드를 하나 생성합니다.
• 필수 조건: 이 전략을 사용할 때 maxSurge 속성은 0으로 설정해야 합니다.

그림으로 시각화하면 다음과 같습니다. (편의상 전체 파드의 개수는 3개로 설정)

yaml 파일 작성

Rolling Update 전략을 설정하려면 spec.strategy 속성과 하위 속성을 작성해야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 5
  revisionHistoryLimit: 5
  replicas: 5
  selector:
    matchLabels:
      app: rolling
  template:
    metadata:
      name: rolling
      labels:
        app: rolling
    spec:
      containers:
        - name: nginx
          image: nginxdemos/hello:plain-text
          ports:
            - name: http
              containerPort: 80
              protocol: TCP

참고로 Deployment 객체는 maxSurge와 maxUnavailable 속성을 설정하지 않으면 기본적으로 각각 25%로 설정됩니다.

Deployment ensures that only a certain number of Pods are down while they are being updated. By default, it ensures that at least 75% of the desired number of Pods are up (25% max unavailable).

Deployment also ensures that only a certain number of Pods are created above the desired number of Pods. By default, it ensures that at most 125% of the desired number of Pods are up (25% max surge).

maxSurge 를 설정하지 않으면 전체 파드의 개수는 최대 125%까지 증가합니다. 예를 들어, 전체 파드가 10개라면 25%인 2.5개가 추가되지만, 파드는 정수로만 생성되므로 반올림되어 최대 3개가 추가됩니다.

maxUnavailable 를 설정하지 않으면 전체 파드 중 최대 25%가 비활성화될 수 있습니다. 예를 들어, 파드 개수가 10개라면 25%인 2.5개가 비활성화되지만, maxSurge 와는 달리 내림 처리가 적용되어 최대 2개 파드만 비활성화됩니다. 이는 서비스 가용성을 보장하기 위해 파드를 비활성화하는 파드 수를 제한하려는 설계입니다.

요약하자면, maxSurge 는 업데이트 중 추가로 생성할 수 있는 파드의 최대 개수를 정의하며, 반올림 처리됩니다. 반면, maxUnavailable 은 업데이트 중 비활성화될 수 있는 파드의 최대 개수를 정의하며, 내림 처리되어 더 보수적으로 적용됩니다.

• minReadySeconds: 새로 생성된 파드가 준비 상태(Ready)로 간주되기 전 대기 시간을 설정합니다.
• revisionHistoryLimit: 이전 버전의 revision을 몇 개까지 저장할지 설정합니다.

참고자료

• Kubernetes 리소스 Deployment에 대해 이해하고 실습해보기 [velog]
• Deployments [Kubernetes]