Kubernetes Disruption Budget Basics

Kubernetes Disruption Budget Basics is the detailed mechanics of the PodDisruptionBudget resource: how the eviction API enforces it, the distinction between voluntary and involuntary disruption it deliberately does and does not cover, the choice between minAvailable and maxUnavailable, and the unhealthy pod eviction policy that governs how a budget interacts with pods that are already failing.

Voluntary vs. Involuntary Disruption

What a PodDisruptionBudget Actually Protects Against

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

A PodDisruptionBudget constrains only voluntary disruptions, evictions explicitly requested through the Kubernetes eviction API, such as a kubectl drain command or the cluster autoscaler consolidating nodes; it has no effect on involuntary disruptions, a node crashing unexpectedly, a kernel panic, a hardware failure, since those events bypass the eviction API entirely and simply remove pods outside any budget's awareness.

The Eviction API Mechanism

How Drain Actually Checks the Budget

kubectl drain node-1 --ignore-daemonsets

kubectl drain does not delete pods directly; it issues eviction requests against the /eviction subresource for each pod, and the API server checks any matching PodDisruptionBudget before approving each request, rejecting it (returning HTTP 429) if honoring it would violate the budget, causing drain to retry until the budget's constraint is satisfied, typically once a replacement pod elsewhere becomes ready.

POST /api/v1/namespaces/{ns}/pods/{name}/eviction

minAvailable vs. maxUnavailable

Choosing the Right Expression for a Given Workload

spec:
  minAvailable: 2

spec:
  maxUnavailable: 1

minAvailable expresses the floor of acceptable capacity directly, intuitive for workloads with a small, fixed replica count where the exact minimum matters; maxUnavailable expresses the ceiling of acceptable loss, which scales naturally as a percentage for workloads whose replica count changes over time (via an autoscaler), since a percentage-based maxUnavailable automatically adjusts its absolute meaning as replica count changes, while a fixed minAvailable does not.

spec:
  maxUnavailable: 10%

Selector Matching Constraints

A Pod Matched by Multiple PDBs Is an Error

Kubernetes explicitly disallows, or at minimum strongly discourages through undefined behavior, a single pod being matched by more than one PodDisruptionBudget's selector simultaneously, since it would be ambiguous which budget's constraint should govern an eviction decision for that pod; disruption budget selectors should be designed to partition workloads cleanly, each pod matched by at most one budget.

kubectl get pdb --all-namespaces -o json | jq '.items[].spec.selector'

Auditing existing selectors before introducing a new PodDisruptionBudget is a reasonable precaution to avoid accidentally introducing overlapping coverage.

Unhealthy Pod Eviction Policy

Handling Already-Failing Pods During Drain

spec:
  unhealthyPodEvictionPolicy: AlwaysAllow

The default IgnoreAllPolicy behavior only ever counts healthy, ready pods toward the disruption budget's availability calculation, which can cause a drain to stall indefinitely if a workload has an already-unhealthy pod that the budget's arithmetic never allows to be evicted; AlwaysAllow permits evicting already-unhealthy pods regardless of the budget's constraint, since evicting a pod that is not currently serving traffic anyway does not actually reduce real availability, unblocking drains that would otherwise wait forever on pods that were never contributing to availability in the first place.

Interaction With Node Draining and Autoscaling

Drains That Never Complete

A PodDisruptionBudget set too strictly relative to a workload's actual replica count, minAvailable equal to the total replica count, for instance, makes every eviction of that workload permanently rejected, causing any node drain touching one of its pods to stall indefinitely; this is a common operational failure mode discovered only when a node drain or cluster autoscaler scale-down unexpectedly hangs.

kubectl get events --field-selector reason=FailedDraining

Checking for repeated eviction rejection events is the standard diagnostic step when a drain operation appears stuck.

Relationship to Reliability and Availability Scope and the Reliability Model

Disruption budget basics are the concrete mechanics behind the controlled-disruption area introduced under reliability and availability scope, and they specifically formalize the reliability model's distinction between planned, Kubernetes-mediated change and unplanned infrastructure failure: a PodDisruptionBudget is deliberately scoped to protect only against the former, since the latter is addressed instead through the redundancy, spread, and fast-recovery mechanisms that make involuntary disruption tolerable even without any budget constraining it.