Does a PodDisruptionBudget protect against a node crash?

No. A node crash is an involuntary disruption. A PDB only limits voluntary disruptions such as drains and autoscaler scale-downs.

Why does my kubectl drain hang?

Most often a PDB allows zero disruptions for a pod on that node, usually because the Deployment has one replica. Check ALLOWED DISRUPTIONS with kubectl get pdb, then add a replica or relax the budget.

Should every Deployment have a PDB?

No. A PDB helps when the workload has more than one replica and you need controlled drains. For a single replica, a PDB only blocks maintenance.

Can I use a percentage in a PDB?

Yes. Both maxUnavailable and minAvailable accept a percentage as well as an absolute number, as the Disruptions page describes.

Kubernetes explained

Pod Disruption Budgets: Keep Pods Up During Node Drains

A PodDisruptionBudget (PDB) limits how many pods of an application can be down at the same time because of voluntary disruptions, such as a node drain for an upgrade or a cluster autoscaler scale-down. It does not protect against hardware failure, and it does not stop a direct kubectl delete of a pod.

By Muhammad Soliman, Founder at SeaGit

Published 11 October 2026 · Updated 11 October 2026

Key takeaways

A PDB covers voluntary disruptions only. Hardware failure, a kernel panic or a network partition are involuntary and a PDB cannot stop them.
kubectl drain and other tools respect a PDB by using the Eviction API. A direct delete bypasses the budget.
A PDB on a single-replica app can block a drain until someone intervenes. Set one only where the replica count allows a disruption.
Choose maxUnavailable for most workloads. Choose minAvailable when you have a quorum or a fixed minimum to keep.

What a PDB limits, and what it does not

The official Disruptions page defines a PDB as a way to limit the number of pods of a replicated application that are down at once from voluntary disruptions. It gives two examples: a quorum-based application that must keep a minimum number of replicas, and a web front end that must keep a percentage of its replicas serving.

The page also lists what counts as voluntary. Deleting the Deployment, updating its pod template so it restarts, deleting a pod by hand, and draining a node for repair or upgrade are all voluntary. A disk fault or a node that vanishes is involuntary, and a PDB has no effect on it.

A working PodDisruptionBudget

A PDB selects pods with a label selector, the same way a Service does. This one keeps at most one pod of my-api unavailable at any time.

yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-api-pdb
  namespace: prod
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-api

With three replicas, a drain can evict one pod at a time. The next eviction waits until a replacement is ready.

To express the other shape, replace maxUnavailable with minAvailable, for example minAvailable: 2 for a three-replica quorum. Set one field, not both. Both fields can be a number or a percentage.

How kubectl drain uses the budget

The safe-drain page says that a successful drain means every pod, except the excluded system pods, has been evicted while respecting the PodDisruptionBudgets you defined. An eviction that would break a budget is rejected for now. The drain tool keeps retrying until the pod can go or a timeout is reached.

bash

# Cordon and evict, respecting PDBs
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

# See what each budget currently allows
kubectl get pdb -n prod
kubectl describe pdb my-api-pdb -n prod

Check ALLOWED DISRUPTIONS before a drain. A zero there means the next eviction will be blocked.

The single-replica trap

A budget that allows zero disruptions blocks every eviction of its pods. On a single-replica Deployment, minAvailable: 1 or maxUnavailable: 0 means the only pod can never be evicted. The drain hangs, the node upgrade stalls, and the cluster autoscaler cannot remove the node. The fix is either to run two replicas or to leave that workload without a PDB and accept the brief outage.

A PDB does not stop kubectl delete pod

The Disruptions page is explicit that tools which respect budgets call the Eviction API instead of deleting pods directly. kubectl delete pod is a direct delete, so a PDB does not stop it. The budget protects the drain path, not every path that removes a pod.

Use a PDB to protect against node maintenance and autoscaler scale-downs.
Do not rely on a PDB to protect a service from an operator who runs kubectl delete pod.
Rolling updates are a separate mechanism. They are governed by the Deployment strategy, not by the PDB.

Choosing maxUnavailable or minAvailable

For a stateless service with N replicas, maxUnavailable: 1 gives a drain one pod at a time and leaves N minus 1 serving. It also works when N changes, because it is not tied to a fixed number. Use minAvailable when the workload needs a fixed floor, such as a three-node consensus cluster that needs two members to stay up.

Two or more replicas, stateless: maxUnavailable: 1.
Quorum system with three members: minAvailable: 2.
Single replica: no PDB, or accept that drains block until the replica is moved manually.