Pod Disruption Budget

PDBs distinguish between voluntary disruptions, such as a node drain, and involuntary disruptions, such as a node failure. Only voluntary disruptions that use the eviction API respect a PDB. They protect against availability incidents during planned operations like EKS version upgrades or node replacement.

How it works

A PodDisruptionBudget selects a set of pods with a label selector and states either minAvailable or maxUnavailable. You set only one of the two. Each accepts a whole number or a percentage, and percentages round up. When a drain asks the API server to evict a pod, the eviction is allowed only if the budget would still be met. Otherwise the request is rejected and the drain keeps retrying.

A PDB does not guarantee availability. If a node fails while the set is already at its minimum, availability can fall below the budget, because that is an involuntary disruption. Deleting a pod directly, rather than evicting it, also does not go through the budget.

A practical example

A web deployment with four replicas that must keep at least two running during drains:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2  # at least 2 replicas must be running
  selector:
    matchLabels:
      app: my-app

During a node upgrade, the drain evicts pods one node at a time. If evicting a pod would leave fewer than two healthy replicas, the eviction waits until a replacement is ready elsewhere.

Common mistakes

• Setting minAvailable equal to the replica count, or maxUnavailable: 0, on a deployment. No eviction is ever allowed, so node drains and cluster upgrades stall.
• Using a PDB with a single replica and expecting zero downtime. One replica cannot satisfy a useful budget without blocking maintenance.
• Setting both minAvailable and maxUnavailable in the same PDB, which is not permitted.
• Writing a selector that matches the wrong pods. An empty selector matches every pod in the namespace.
• Expecting a PDB to protect against node failure or a bad rollout. It governs evictions only.

When to use it and when not to

Use a PDB for production services with several replicas, and for quorum-based systems where maxUnavailable: 1 or a minAvailable equal to the quorum keeps the cluster healthy. The Kubernetes documentation suggests a different approach for a single-instance stateful application that needs manual coordination: maxUnavailable: 0, removing the PDB when disruption is acceptable. Skip PDBs for restartable batch Jobs, where the Job controller creates replacements. Pair them with sensible replica counts from the Horizontal Pod Autoscaler. Our Kubernetes consulting service covers upgrade planning.

See also

• Kubernetes
• Horizontal Pod Autoscaler
• EKS
• StatefulSet