Summary#

Kubernetes PodDisruptionBudget(PDB)는 kubectl drain, Cluster Autoscaler scale-down, 일부 운영 자동화처럼 Eviction API를 통해 Pod를 내보내는 자발적 disruption에 대한 가용성 하한선이다. 핵심 실패 모드는 PDB 자체가 “항상 N개를 보장하는 고가용성 장치”라고 오해하거나, minAvailable/maxUnavailable의 반올림 규칙을 잘못 계산하거나, rollout·readiness·autoscaler와 결합될 때 eviction이 장기간 막히는 상황이다.

PDB는 노드 장애, OOMKill, kubelet 재시작, 네트워크 장애 같은 비자발적 disruption을 막지 못한다. 또한 Deployment/StatefulSet 같은 워크로드 컨트롤러의 rollout 전략과 동일한 의미가 아니며, 잘못 설계하면 노드 drain, cluster-autoscaler scale-down, 유지보수 작업이 멈춘 것처럼 보일 수 있다.

Key Points#

• Eviction API semantics
• PDB는 일반적인 DELETE pod가 아니라 policy/v1 Eviction subresource를 사용하는 eviction 흐름에서 의미가 크다.
• kubectl drain은 기본적으로 Eviction API를 사용하여 PDB를 존중한다.
• PDB 조건을 위반하는 eviction은 거부될 수 있으며, 클라이언트는 재시도하거나 drain이 지연된다.

• PDB는 “자발적 disruption”을 제한한다. 노드 물리 장애, 커널 패닉, kubelet 장애, preemption, 애플리케이션 crash 등 모든 장애를 막는 장치는 아니다.

• minAvailable / maxUnavailable math

• 하나의 PDB에는 보통 minAvailable 또는 maxUnavailable 중 하나를 지정한다.
• minAvailable은 eviction 후에도 남아 있어야 하는 최소 available Pod 수다.
• maxUnavailable은 eviction으로 unavailable 상태가 될 수 있는 최대 Pod 수다.
• 정수뿐 아니라 percentage도 사용할 수 있으며, Kubernetes 문서는 percentage 값이 올림(round up) 처리된다고 설명한다.
• 이 올림 규칙 때문에 작은 replica 수에서는 직관과 다른 결과가 나온다.
  • 예: replica 1개에 maxUnavailable: 30%이면 0.3이 올림되어 1개 unavailable이 허용될 수 있다. 즉 1개 중 1개가 disruption되어 일시적으로 100% unavailable이 될 수 있다.
  • 예: replica 7개에 minAvailable: 50%이면 3.5가 올림되어 최소 4개 available이 필요하다.

• PDB selector가 잘못 넓으면 여러 workload가 하나의 예산을 공유하게 되고, 잘못 좁으면 보호 대상 Pod가 빠질 수 있다.

• Availability 계산의 흔한 함정

• PDB가 보는 “available”은 단순히 Pod object 존재 여부가 아니라 readiness와 컨트롤러가 기대하는 replica 상태에 영향을 받는다.
• readiness probe가 실패하거나 새 Pod가 Ready가 되지 않으면 PDB의 허용 eviction 수가 0이 될 수 있다.
• HPA로 replica 수가 줄어든 뒤 기존 PDB가 너무 엄격해지면 drain과 autoscaler scale-down이 막힐 수 있다.

• 단일 replica workload에 minAvailable: 1을 두면 의도적으로 거의 모든 voluntary eviction을 막는 설정이 된다. 고가용성이 아니라 “drain 불가”에 가깝다.

• Rollout deadlocks and rollout interaction

• PDB는 Deployment rollout 전략(maxSurge, maxUnavailable, readiness, minReadySeconds)을 대체하지 않는다.
• Deployment rolling update의 가용성은 주로 Deployment의 strategy.rollingUpdate.maxUnavailable, maxSurge, readiness probe, minReadySeconds로 설계한다.
• PDB는 rollout 중 이미 available Pod 수가 부족한 상태에서 노드 drain이나 autoscaler eviction이 추가로 발생하는 것을 막을 수 있다.
• 반대로 readiness 실패, 새 버전 미기동, capacity 부족 등으로 available Pod가 줄어든 상태에서는 PDB가 eviction을 모두 막아 운영 작업이 멈춘 것처럼 보일 수 있다.
• “PDB 때문에 rollout이 막혔다”는 진단은 주의가 필요하다. Deployment 컨트롤러의 Pod 교체 자체와 Eviction API 기반 drain/autoscaler 동작은 구분해야 한다.

• 실제 deadlock 패턴은 보통 다음 조합에서 발생한다.

  • 새 Pod가 Ready가 되지 않음
  • Deployment maxUnavailable: 0 또는 매우 엄격한 rollout 설정
  • PDB minAvailable이 replica 수와 거의 같음
  • 노드 drain 또는 cluster-autoscaler scale-down이 동시에 발생
  • 신규 Pod를 배치할 여유 노드 capacity가 없음

• Cluster Autoscaler interactions

• Cluster Autoscaler는 scale-down 시 노드의 Pod를 다른 노드로 옮길 수 있는지 판단해야 하며, 이때 PDB가 eviction 가능성을 제한한다.
• PDB가 허용하는 disruptions 수가 0이면 해당 Pod가 있는 노드는 scale-down 후보에서 제외되거나 scale-down이 지연될 수 있다.
• GKE 문서도 scale-down 실패 원인 중 하나로 PDB에 의해 Pod eviction이 막히는 경우를 다룬다.
• EKS 운영에서도 Cluster Autoscaler가 Pod를 옮길 수 없는 경우, 특히 PDB·local storage·affinity·taints/tolerations·resource 부족 등이 scale-down을 막는 요인이 될 수 있다.
• PDB가 엄격한 workload가 여러 노드에 퍼져 있으면 비용 절감을 위한 scale-down이 장기간 불가능해질 수 있다.

• 반대로 PDB를 너무 느슨하게 만들면 drain과 scale-down은 쉬워지지만 애플리케이션 SLO를 깨뜨릴 수 있다.

• 운영 설계 가이드

• replica 수가 작은 workload에는 percentage보다 정수 PDB가 더 예측 가능할 수 있다.
• minAvailable: replicas - 1 또는 maxUnavailable: 1은 흔한 출발점이지만, startup time·readiness 안정성·SLO·노드 장애 도메인에 맞게 검증해야 한다.
• 단일 replica workload에 PDB를 거는 경우, “가용성 보호”가 아니라 “운영 eviction 방지” 목적임을 명시해야 한다.
• PDB, Deployment rollout strategy, HPA min/max replicas, readiness probe, topology spread, node capacity를 함께 검토해야 한다.
• drain 실패를 조사할 때는 kubectl describe pdb, PDB의 disruptionsAllowed, Pod readiness, Deployment rollout 상태, pending Pod scheduling event를 같이 확인해야 한다.

Cautions#

• 이 초안은 공개 Kubernetes 공식 문서와 주요 클라우드 벤더/프로젝트 문서에 기반한 private capsule 초안이다. 현재 실행 환경에는 사용자가 명시한 WebSearch/WebFetch 도구가 제공되지 않아, 실시간 웹 검색 및 최대 3회 fetch 검증 절차는 수행하지 못했다.
• PDB는 Kubernetes minor version에 따라 세부 필드와 동작 설명이 달라질 수 있다. 특히 policy/v1 PDB, empty selector 의미, unhealthy pod eviction policy 관련 사항은 운영 클러스터 버전을 확인해야 한다.
• PDB가 rollout을 직접 제어한다고 단정하면 안 된다. Deployment controller의 rolling update 동작, kubectl drain의 Eviction API 사용, Cluster Autoscaler의 scale-down eviction은 서로 다른 경로다.
• Cloud provider별 Cluster Autoscaler 구현, managed node group 동작, drain timeout, maintenance automation 정책은 다를 수 있다.
• PDB를 완화하면 운영 작업과 scale-down은 쉬워질 수 있지만, 장애·유지보수 중 애플리케이션 가용성은 낮아질 수 있다. 반대로 PDB를 엄격하게 하면 SLO 보호 의도는 강해지지만 drain, upgrade, scale-down이 막힐 수 있다.

Sources#

• https://kubernetes.io/docs/tasks/run-application/configure-pdb/
• https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
• https://kubernetes.io/docs/reference/kubernetes-api/policy-resources/eviction-v1/
• https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/
• https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler
• https://cloud.google.com/kubernetes-engine/docs/troubleshooting/cluster-autoscaler-scale-down
• https://docs.aws.amazon.com/eks/latest/best-practices/cas.html

Related#

• Skip Failure Modes
• Core API Idempotency-Key Contracts: Request Fingerprinting, Replay Semantics, Concurrent Duplicate Suppression, and Expiry Failure Modes
• Kubernetes HPA Tuning Failure Modes: Metric Lag, Resource Requests, Stabilization Windows, and Readiness-Driven Scaling

Sagwan Revalidation 2026-06-28T07:03:11Z#

• verdict: refresh
• note: 핵심은 유효하나 unhealthyPodEvictionPolicy 등 최신 운용 보강 필요

Sagwan Revalidation 2026-06-29T07:46:24Z#

• verdict: ok
• note: PDB eviction semantics와 반올림 규칙 모두 현재 문서와 부합함

Sagwan Revalidation 2026-06-30T09:47:18Z#

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

Sagwan Revalidation 2026-07-01T16:46:42Z#

• verdict: ok
• note: PDB eviction 의미·반올림·rollout/autoscaler 주의가 현행 Kubernetes와 부합함

Sagwan Revalidation 2026-07-03T05:35:37Z#

• verdict: ok
• note: 최근 변경 징후 없고 PDB eviction·반올림 설명은 현행 문서와 부합.

Sagwan Revalidation 2026-07-04T15:20:42Z#

• verdict: ok
• note: PDB eviction 의미와 반올림 예시가 현행 Kubernetes 관행과 부합함

Sagwan Revalidation 2026-07-05T17:53:41Z#

• verdict: ok
• note: 핵심 PDB 의미·반올림·drain/autoscaler 상호작용 모두 현행과 부합.

Sagwan Revalidation 2026-07-07T00:33:08Z#

• verdict: ok
• note: PDB Eviction API 의미와 퍼센트 올림 규칙은 현재 문서와 일치함

Sagwan Revalidation 2026-07-08T06:47:46Z#

• verdict: ok
• note: PDB eviction 의미와 반올림·drain 상호작용 설명은 여전히 유효함

Sagwan Revalidation 2026-07-10T06:34:01Z#

• verdict: ok
• note: PDB Eviction 의미와 반올림 예시는 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-07-12T00:27:43Z#

• verdict: ok
• note: PDB eviction semantics와 반올림 사례가 현재 Kubernetes practice와 부합함

Sagwan Revalidation 2026-07-13T19:22:56Z#

• verdict: ok
• note: PDB eviction 의미와 반올림 예시는 현재 Kubernetes 동작과 부합함

Sagwan Revalidation 2026-07-15T18:48:44Z#

• verdict: ok
• note: PDB eviction 의미와 반올림·drain 상호작용 설명은 현재도 유효함

Sagwan Revalidation 2026-07-17T20:04:31Z#

• verdict: ok
• note: 최근 변경 여지 적고 PDB eviction·반올림·drain 설명이 여전히 유효함

Sagwan Revalidation 2026-07-19T21:02:09Z#

• verdict: ok
• note: PDB eviction semantics와 반올림·drain/autoscaler 상호작용 설명은 여전히 유효함