쿠버네티스 PodDisruptionBudget — 자발적 중단으로부터 Pod를 보호하는 방법

지난 글에서 kubelet이 리소스 압박 시 Pod를 강제 퇴출하는 메커니즘을 살펴봤습니다. 이번 글에서는 방향을 바꿔, 운영자나 도구가 의도적으로 Pod를 제거하려 할 때 가용성을 지키는 방법인 PodDisruptionBudget을 다룹니다.

자발적 중단이란?

쿠버네티스에서 Pod 중단은 크게 두 종류로 나뉩니다. 비자발적 중단(Involuntary Disruption)은 노드 하드웨어 장애, 커널 패닉, OOM 킬처럼 예기치 않게 발생합니다. 반면 자발적 중단(Voluntary Disruption)은 kubectl drain, 롤링 업데이트, Cluster Autoscaler의 노드 축소처럼 사람 또는 시스템이 의도적으로 시작하는 작업에서 발생합니다.

PDB는 자발적 중단에만 효과가 있습니다. 비자발적 중단은 막을 수 없으므로, 그쪽은 레플리케이션과 멀티존 배포로 대비해야 합니다.

PDB 개념 — minAvailable·maxUnavailable 설정

PDB 핵심 필드

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
  namespace: production
spec:
  minAvailable: 2          # 최소 2개 Pod가 Available이어야 함
  # maxUnavailable: 1      # 또는 이 방식으로 표현 (둘 중 하나만)
  selector:
    matchLabels:
      app: web-server

minAvailable과 maxUnavailable은 둘 중 하나만 지정합니다. 정수 또는 퍼센트("75%") 모두 허용합니다. 퍼센트 지정 시 현재 replicas 기준으로 계산하므로, 스케일 아웃/인 시에도 자동 적용됩니다.

필드	의미	예시
`minAvailable: 2`	최소 2개 Pod Available	replicas=4 → 최대 2개 동시 중단 가능
`maxUnavailable: 1`	최대 1개 Pod Unavailable	replicas=4 → 3개 이상 Available 유지
`minAvailable: "75%"`	replicas×75% 이상 유지	replicas=8 → 최소 6개 유지

Eviction API와 PDB 동작 원리

kubectl drain이나 롤링 업데이트 컨트롤러는 Pod를 직접 삭제하지 않고 Eviction API(v1/eviction 서브리소스)를 통해 제거 요청을 보냅니다. kube-apiserver는 이 요청을 받으면 해당 Pod가 속한 PDB를 검색하고 disruptionsAllowed 값을 확인합니다.

disruptionsAllowed = currentReplicas - minAvailable
                   = 4 - 2 = 2  →  최대 2개 동시 제거 가능

disruptionsAllowed > 0이면 Eviction을 허용하고 Pod를 삭제합니다. 0이면 HTTP 429(Too Many Requests)를 반환해 요청자가 나중에 재시도하도록 합니다.

PDB 자발적 중단 처리 흐름

실습: PDB 설정과 drain 테스트

# PDB 생성
kubectl apply -f - <<EOF
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web-server
EOF

# 현재 PDB 상태 확인
kubectl get pdb web-pdb
# NAME      MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
# web-pdb   2               N/A               2                     10s

# 노드 드레인 시도 (PDB가 보호 중인 Pod 있을 경우 429로 대기)
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

드레인 명령은 PDB가 허용할 때까지 반복 재시도합니다. 새 Pod가 다른 노드에서 Running 상태가 되면 disruptionsAllowed가 다시 증가하고, 다음 Pod를 제거합니다.

PDB 설계 시 주의사항

단일 Pod Deployment에 minAvailable: 1 설정 금지. replicas=1이고 minAvailable: 1이면 disruptionsAllowed=0이 돼 영구 차단 상태가 됩니다. drain이 무한 대기하거나 업그레이드가 멈춥니다.

# 위험한 설정 예시
spec:
  replicas: 1            # Pod 1개
  # PDB에 minAvailable: 1 → drain 영구 차단!

대신 minAvailable: 0 또는 maxUnavailable: 1로 설정하거나, replicas를 2 이상으로 늘려야 합니다.

StatefulSet에 PDB를 반드시 설정하세요. 데이터베이스나 메시지 큐처럼 상태를 가진 워크로드는 갑작스러운 Pod 제거가 데이터 손실이나 쿼럼 붕괴로 이어질 수 있습니다. 예를 들어 3개 노드 Kafka 클러스터라면 minAvailable: 2를 설정해 과반수 이상이 항상 살아있도록 강제합니다.

운영 환경 권장 패턴

# HPA와 함께 사용할 때는 퍼센트 기반 추천
spec:
  minAvailable: "60%"   # replicas 변동에도 자동 조정
  selector:
    matchLabels:
      app: my-app

# 중요도 높은 서비스는 네임스페이스별 PDB 일괄 설정
# ArgoCD ApplicationSet이나 Helm values로 관리

PDB는 kubectl get pdb -A로 전체 네임스페이스를 확인할 수 있습니다. ALLOWED DISRUPTIONS가 0인 채로 오래 유지되면 노드 드레인이나 업그레이드가 멈출 수 있으니 주기적으로 모니터링하세요.

지난 글: 쿠버네티스 Pod 퇴출(Eviction) — kubelet의 리소스 보호 메커니즘

다음 글: 쿠버네티스 LimitRange — 네임스페이스 내 리소스 기본값과 제한

읽어주셔서 감사합니다. 😊