[kubernetes] RollingUpdate 와 PodDisruptionBudget(PDB)

들어가기 앞서

Kubernetes에서 애플리케이션을 운영할 때 무중단 배포와 가용성 유지는 중요한 요소입니다. 이를 위해 RollingUpdate와 PodDisruptionBudget(PDB)을 활용할 수 있습니다. 이번 포스팅에서는 각각의 개념과 차이점을 자세히 살펴보고, 함께 사용하는 방법을 알아보겠습니다.

1. RollingUpdate : 무중단 배포를 위한 전략

1.1 RollingUpdate 란?

RollingUpdate는 Kubernetes의 Deployment 전략 중 하나로, Pod를 한 번에 하나씩 교체하며 무중단으로 새로운 버전을 배포하는 방식입니다. 애플리케이션을 운영하면서 서비스 중단 없이 업데이트해야 할 때 사용됩니다.

1.2 RollingUpdate 설정 및 YAML 예제

Deployment에서 strategy를 RollingUpdate로 설정하면, maxSurge와 maxUnavailable 값을 지정하여 배포 중 Pod의 동작 방식을 제어할 수 있습니다. 아래는 RollingUpdate 전략 설정 예제입니다. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:v2

• 새로운 Pod(새 버전)가 하나 추가 생성됨 (최대 maxSurge 개수까지)
• 새 Pod가 정상적으로 준비되면 기존 Pod 중 하나를 삭제
• 위 과정을 반복하여 모든 Pod를 새 버전으로 교체

1.3 주요 설정 값

• maxSurge
  • 원하는 복제본 수를 초과하여 추가 파드 인스턴스를 허용하는 옵션
  • 기본값은 25%이며, 백분율은 반올림됨
• maxUnavailable
  • 업데이트 중에 사용 불가능한 파드 인스턴스 수를 제한하는 옵션
  • 기본값은 25%이며, 백분율은 버림됨

1.4 RollingUpdate 동작 방식

default maxSurge and maxUnavailable

원하는 복제본 수가 세 개라면, 이러한 속성들의 기본값이 25%인 경우, maxSurge는 전체 파드 수를 네 개로 증가시켰으며, maxUnavailable은 한 개의 파드도 사용할 수 없도록 허용하지 않았습니다. 즉, 항상 세 개의 파드가 사용 가능해야 했습니다. 이는 그림 9.12에 나와 있습니다.

 

maxSurge=1 and maxUnavailable=1

이 경우에는 한 개의 복제본이 사용 불가능할 수 있으므로, 원하는 복제본 수가 세 개인 경우에는 두 개만 사용 가능하면 됩니다. 따라서 롤아웃 프로세스는 즉시 한 개의 파드를 삭제하고 두 개의 새 파드를 생성합니다. 이렇게 하면 두 개의 파드가 사용 가능하고 최대 파드 수가 초과되지 않습니다(이 경우 최대 값은 네 개입니다—세 개와 maxSurge의 한 개).

 

두 개의 새 파드가 사용 가능해지면 남아 있는 두 개의 이전 파드가 삭제됩니다. 이것은 약간 이해하기 어려울 수 있으며, 특히 maxUnavailable 속성으로 인해 헷갈릴 수 있습니다. 이 속성은 허용되는 사용 불가능한 파드의 최대 수인 것처럼 보이지만, 이전 그림을 자세히 살펴보면 maxUnavailable이 1로 설정되어 있더라도 두 개의 사용 불가능한 파드가 있는 것을 볼 수 있습니다.

 

maxUnavailable은 원하는 복제본 수에 대해 상대적입니다. 복제본 수가 세 개로 설정되고 maxUnavailable이 한 개로 설정된 경우, 이는 업데이트 프로세스가 항상 두 개(3에서 1을 뺀 값)의 파드를 사용 가능한 상태로 유지해야 하며, 사용 불가능한 파드의 수가 한 개를 초과할 수 있다는 것을 의미합니다.

2. PodDisruptionBudget(PDB): 가용성을 보장하는 정책

2.1 PDB 란?

PodDisruptionBudget(PDB)는 Kubernetes 클러스터에서 의도적인 장애(Disruption) 발생 시, 특정 개수 이상의 Pod를 유지하도록 보장하는 정책입니다.

2.2 PDB 설정 예제

PDB는 minAvailable 또는 maxUnavailable 값을 지정하여 적용할 수 있습니다.

 

최소 2개의 Pod를 유지하는 PDB

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2       
  selector:
    matchLabels:
      app: my-app

 

최대 1개의 Pod만 중단 가능하도록 설정

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 1    
  selector:
    matchLabels:
      app: my-app

2.3 PDB 주요 기능

• 의도적인 장애 시 최소한의 가용성 유지
• 노드 업그레이드, 클러스터 유지보수 등에서 Pod가 한꺼번에 사라지는 것을 방지
• 강제적인 장애(예: 노드 장애, OOM)에는 영향을 주지 않음

3. RollingUpdate 와 PDB 의 차이점

4. RollingUpdate 와 PDB 를 함께 사용하기

4.1 함께 설정한 예제

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:v2
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

4.2 기대 효과

• RollingUpdate: 애플리케이션 배포 시 트래픽을 유지하며 새로운 버전으로 교체
• PDB: 노드 유지보수 같은 클러스터 이벤트 중에도 최소한의 가용성을 보장
• 결론: RollingUpdate와 PDB를 함께 사용하면 배포 중에도 가용성을 유지하면서 운영 안정성을 높일 수 있음

5. 마무리

Kubernetes에서 RollingUpdate는 무중단 배포를 위한 전략이며, PodDisruptionBudget(PDB)는 의도적인 장애 발생 시 최소한의 Pod 가용성을 보장하는 정책입니다. 이를 함께 설정하면 서비스 중단 없이 안정적인 애플리케이션 운영이 가능합니다.