Necessity of PDB (Pod Disruption Budget)

Pod Disruption Budget (PDB) is a rule in k8s that limits the number of pods that can simultaneously disappear to maintain service availability, even when unavoidable disruption operations occur.

In other words, it declares the number of pods that can be safely terminated during operation.

In k8s, pods are forcibly terminated or moved in various situations, for example:

1. Node kernel updates
2. Node drain
3. Autoscaler scales down nodes
4. DaemonSet rollout
5. Deployment rolling update without PDB
6. Spot instance termination
7. Automatic cleanup of failed nodes

The problem is that such planned disruptions can kill multiple pods at once, potentially leading to a momentary service outage or a situation where the entire traffic cannot be received due to readiness failures.

PDB prevents this.

How PDB Works #

PDB is defined by one of the following:

• minAvailable: Specifies the minimum number of pods that must be available.
• maxUnavailable: Specifies the maximum number of pods that can be unavailable at one time.

If minAvailable: 2, it's a rule in k8s that at least two pods must be alive, and this rule is never broken.

This means that even if a node is drained, a kill operation that violates the PDB will not be executed.

This allows for fault-tolerant rolling update compensation. If there are three pods, but the readiness timeout is long or the initialization time is extended, a situation where only one pod remains during a rolling update can occur, and PDB can prevent this.

Alternatively, service availability is maintained during node failures (drain/cordon).

kubectl drain nodex-xxx --ignore-daemonsets

Without PDB, multiple pods can be evicted instantly, leading to service disruption, but with PDB, k8s determines that killing a pod would violate the PDB and thus does not kill it.

As a result, even when an administrator performs a drain, pods are safely and sequentially moved within the PDB conditions.

It also prevents conflicts with the cluster autoscaler. Even during node scale-in, while the CA attempts to evict pods to remove a node, if a PDB exists, it detects a violation and does not remove the node.

Constraints are guaranteed even when spot instances terminate (especially important for StatefulSets).

It also protects services with readiness delays, heavy initialization, or cache warm-up. Services with slow initialization experience a significant drop in stability when one pod dies and a new one starts up. PDB enforces a minimum number of running pods, preventing the entire service from becoming unstable due to pods that are still warming up.

Without PDB #

• 503 errors during node drain
• Readiness timeouts during rolling updates -> drastic drop in overall service availability
• Mass pod eviction during CA scale-in -> service loss
• Simultaneous pod termination during spot node evacuation
• Loss of stateful data like Redis/Elasticsearch
• Downtime due to DaemonSet interference without PDB

PDB is a core feature for protecting service availability during all planned operations where Kubernetes terminates pods, making it a necessary option for availability.