Kubernetes PodDisruptionBudget Failure Modes: Eviction Semantics, Percentage Rounding, Rollout Deadlocks, and Autoscaler Interactions

Kubernetes PodDisruptionBudget(PDB)는 “자발적 중단(voluntary disruption)”을 제한하기 위한 안전장치다. kubectl drain, Kubernetes Eviction API, 일부 노드 유지보수/자동화 도구처럼 Pod를 Eviction API로 축출 하는 경로에서는 PDB가 적용된다. 반면 노드 장애, OOM, 커널 패닉, 직접 kubectl delete pod, 컨트롤러의 롤링 업데이트 동작 등에는 PDB가 기대한

Summary#

Kubernetes PodDisruptionBudget(PDB)는 “자발적 중단(voluntary disruption)”을 제한하기 위한 안전장치다. kubectl drain, Kubernetes Eviction API, 일부 노드 유지보수/자동화 도구처럼 Pod를 Eviction API로 축출하는 경로에서는 PDB가 적용된다. 반면 노드 장애, OOM, 커널 패닉, 직접 kubectl delete pod, 컨트롤러의 롤링 업데이트 동작 등에는 PDB가 기대한 방식으로 “삭제를 막는 락”처럼 동작하지 않을 수 있다.

주요 실패 모드는 다음 네 가지다.

Eviction semantics 오해: PDB는 모든 Pod 삭제를 막지 않으며, Eviction API 기반의 voluntary eviction에 주로 작동한다.
percentage rounding 함정: minAvailable 또는 maxUnavailable을 퍼센트로 지정하면 정수 반올림 규칙 때문에 소규모 replica에서 예상보다 더 엄격하거나 더 느슨하게 작동할 수 있다.
rollout deadlock / drain block: Deployment/StatefulSet의 maxUnavailable, readiness 문제, PDB 설정이 맞물리면 rollout이나 node drain이 진행되지 않는 상황이 생길 수 있다.
autoscaler interaction: Cluster Autoscaler 등은 PDB를 존중하기 때문에, PDB가 너무 엄격하면 scale-down, node drain, 노드 교체가 장기간 막힐 수 있다.

Key Points#

PDB는 policy/v1 리소스로, 선택된 Pod 집합에 대해 동시에 허용 가능한 disruption 수를 제한한다.
PDB는 보통 다음 두 방식 중 하나로 정의한다.
minAvailable: 최소한 몇 개 또는 몇 %의 Pod가 계속 available해야 하는지 지정.
maxUnavailable: 최대 몇 개 또는 몇 %의 Pod가 unavailable해도 되는지 지정.
minAvailable과 maxUnavailable은 동시에 설정할 수 없다.
PDB가 적용되는 대표 경로:
Eviction API
kubectl drain
Eviction API를 사용하는 운영 자동화
노드 유지보수, 노드 축소, 일부 autoscaler 동작
PDB가 기대처럼 보호하지 못하는 경로:
물리/가상 노드 장애
kubelet 또는 컨테이너 런타임 장애
커널 패닉
네트워크 파티션
직접적인 Pod 삭제
컨트롤러의 rollout 정책 자체
Kubernetes 공식 문서는 rolling upgrade로 인해 삭제되거나 unavailable해진 Pod는 disruption budget 계산에는 포함되지만, Deployment/StatefulSet 같은 컨트롤러가 rolling update를 수행할 때 PDB가 컨트롤러를 직접 제한하는 것은 아니라고 설명한다. 즉 rollout 안전성은 PDB만이 아니라 해당 컨트롤러의 maxUnavailable, maxSurge, readiness/liveness/startup probe, progressDeadlineSeconds, StatefulSet update strategy와 함께 설계해야 한다.
percentage rounding은 작은 replica 수에서 특히 위험하다.
예: replica 1개에 maxUnavailable: 30%를 설정하면 “0.3개”가 아니라 정수 반올림 규칙에 따라 1개 disruption이 허용될 수 있다.
예: replica 3개에 minAvailable: 50%를 설정하면 실제 요구 available 수는 2개가 될 수 있다.
이 때문에 “절반 정도 유지”라는 의도와 실제 허용 disruption 수가 달라질 수 있다.
PDB는 애플리케이션의 고가용성을 보장하지 않는다. PDB는 “언제 Pod를 안전하게 축출할 수 있는가”에 대한 정책일 뿐이다.
PDB가 너무 엄격하면 다음 운영 작업이 막힐 수 있다.
kubectl drain
managed Kubernetes node upgrade
node pool 교체
Cluster Autoscaler scale-down
비용 최적화용 노드 축소
spot/preemptible node 교체 자동화
PDB와 rollout 설정이 충돌하는 대표 패턴:
replicas가 1인데 minAvailable: 1
replicas가 2인데 minAvailable: 2
readiness probe가 오래 실패하는데 PDB가 available Pod 수를 엄격히 요구
Deployment maxUnavailable: 0 또는 매우 낮은 값과 PDB minAvailable이 동시에 보수적으로 설정됨
StatefulSet에서 순차 업데이트 중 새 Pod가 Ready가 되지 않아 기존 Pod를 더 이상 내릴 수 없음
kubectl drain이 PDB 때문에 실패하거나 대기하는 경우, 메시지는 보통 “Cannot evict pod as it would violate the pod's disruption budget” 계열로 나타난다.
Cluster Autoscaler는 scale-down 후보 노드의 Pod를 다른 곳으로 옮길 수 있는지 평가할 때 PDB를 고려한다. 따라서 PDB가 eviction을 허용하지 않으면 해당 노드는 제거 대상에서 제외되거나 scale-down이 지연될 수 있다.
운영 권장사항:
replica 수가 작은 워크로드에서는 percentage보다 정수 값을 선호한다.
단일 replica 워크로드에 PDB를 붙일 때는 drain/upgrade가 막히는 것을 명시적으로 감수해야 한다.
Deployment rollout 설정과 PDB를 함께 검토한다.
StatefulSet은 순서 보장과 readiness 대기 특성 때문에 PDB와 결합 시 deadlock 가능성을 더 신중히 본다.
PDB가 있는 namespace/service에 대해 정기적으로 drain simulation 또는 upgrade rehearsal을 수행한다.
kubectl get pdb에서 ALLOWED DISRUPTIONS가 0인 상태가 장기간 지속되는지 모니터링한다.
autoscaler 이벤트와 PDB 상태를 함께 관찰한다.
critical workload에는 PDB뿐 아니라 anti-affinity, topology spread constraints, multi-zone scheduling, readiness 설계가 함께 필요하다.

Cautions#

이 초안은 공개 Kubernetes 문서와 공개 Cluster Autoscaler 문서를 기준으로 작성한 private capsule 초안이다.
현재 실행 환경에는 명시적인 WebSearch/WebFetch 도구가 제공되지 않아, 사용자가 요구한 “WebSearch 선행” 및 “WebFetch 최대 3회” 절차를 실제 도구 호출로 검증하지 못했다. 아래 Sources에는 신뢰 가능한 공개 URL만 포함했다.
Kubernetes 버전별로 PDB 동작, Eviction API 세부 구현, controller behavior, managed Kubernetes upgrade behavior가 다를 수 있다. 실제 적용 전에는 대상 클러스터 버전의 공식 문서를 확인해야 한다.
PDB는 직접적인 kubectl delete pod나 노드 장애 같은 involuntary disruption을 막는 보안/가용성 경계가 아니다.
maxUnavailable 또는 minAvailable의 percentage rounding은 운영자가 직관적으로 예상하는 값과 달라질 수 있다. 특히 replica 수가 1~3개인 워크로드에서는 반드시 계산 결과를 확인해야 한다.
PDB로 rollout deadlock이 “반드시” 발생하는 것은 아니다. deadlock 여부는 replica 수, readiness 상태, controller rollout 설정, scheduling 가능성, resource quota, affinity/anti-affinity, topology constraints, autoscaler 상태에 따라 달라진다.
Cluster Autoscaler의 동작은 클라우드 제공자, managed Kubernetes 배포판, autoscaler 버전, scale-down flags, node group 설정에 따라 달라질 수 있다.
ALLOWED DISRUPTIONS: 0은 항상 장애는 아니지만, node drain/scale-down/upgrade 시에는 진행 차단 신호가 될 수 있다.

Sources#

https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
https://kubernetes.io/docs/tasks/run-application/configure-pdb/
https://kubernetes.io/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1/
https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md

Sagwan Revalidation 2026-07-08T19:00:48Z#

verdict: refresh
note: 최신 PDB 관행에는 unhealthyPodEvictionPolicy 반영이 필요하다.

Sagwan Revalidation 2026-07-10T23:19:09Z#

verdict: ok
note: PDB eviction 범위, 반올림, rollout/autoscaler 상호작용 모두 여전히 유효함

Sagwan Revalidation 2026-07-12T16:45:04Z#

verdict: ok
note: 핵심 PDB 동작과 policy/v1·Eviction semantics가 여전히 유효함

Sagwan Revalidation 2026-07-14T13:24:08Z#

verdict: ok
note: PDB eviction 의미론과 반올림·rollout·autoscaler 상호작용 설명이 여전히 유효함

Sagwan Revalidation 2026-07-16T14:32:02Z#

verdict: ok
note: PDB 핵심 semantics와 rounding·drain·autoscaler 설명은 여전히 유효함

Sagwan Revalidation 2026-07-18T15:35:39Z#

verdict: ok
note: PDB의 eviction 적용 범위와 반올림·롤아웃·CA 상호작용 설명은 유효함

Sagwan Revalidation 2026-07-20T16:46:02Z#

verdict: ok
note: PDB semantics·반올림·rollout/autoscaler 상호작용 설명은 현재도 유효함