Pod Disruption Budgets (PDBs) don’t actually prevent evictions; they define a minimum number of pods that must remain available during voluntary disruptions.
Let’s see a PDB in action. Imagine you have a critical stateless web service running on EKS. You want to ensure at least 80% of its pods are always up and serving traffic, even if you need to perform maintenance like node upgrades or drain nodes.
Here’s the YAML for a PDB that enforces this:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-web-service-pdb
spec:
minAvailable: 2 # Or use maxUnavailable: 1
selector:
matchLabels:
app: my-web-service
In this example, minAvailable: 2 means that at any given time, at least two pods matching the label app: my-web-service must be running and available. If you have a Deployment with 3 replicas, and you try to drain a node, Kubernetes won’t evict a pod if doing so would bring the running count below 2. It will wait for other pods to become available or for you to manually intervene.
The core problem PDBs solve is ensuring application availability during planned maintenance events orchestrated by Kubernetes. Without them, actions like kubectl drain on a node could evict all pods from that node simultaneously, leading to an outage for your service. PDBs provide a safety net, allowing you to perform these operations with confidence.
Internally, the Kubernetes API server and the controller manager work together. When a voluntary disruption event occurs (like a node drain initiated by kubectl drain), the controller manager checks all PDBs that apply to the pods being evicted. If evicting a pod would violate a PDB’s minAvailable or maxUnavailable constraint, the eviction request is temporarily blocked. The controller will then signal that the eviction is "in progress" but cannot proceed until the condition is met (e.g., another pod becomes available or the PDB is modified).
Here are the key levers you control:
minAvailable: Specifies the minimum number of pods that must be running. You can provide an integer (e.g.,2) or a percentage (e.g.,80%). If you have 10 pods andminAvailable: 80%, at least 8 pods must be available.maxUnavailable: Specifies the maximum number of pods that can be unavailable. This is the inverse ofminAvailable. If you have 10 pods andmaxUnavailable: 2, it means at least 8 pods must be available, which is equivalent tominAvailable: 8. You can also provide an integer or a percentage.selector: This is crucial. It’s a standard Kubernetes label selector that targets the pods the PDB should protect. Ensure this selector precisely matches the labels of the Deployments, StatefulSets, or ReplicaSets you want to safeguard. Mismatched selectors mean the PDB won’t apply.
When you initiate a node drain using kubectl drain <node-name> --ignore-daemonsets --delete-local-data, Kubernetes attempts to evict pods from that node. If a pod is protected by a PDB, and evicting it would violate the PDB’s constraints, the eviction will be put on hold. The kubectl drain command will show pods as being "evicted" but they will remain on the node until the PDB condition is satisfied.
Consider a scenario where you have 5 replicas of your application, and you set minAvailable: 4. If you try to drain a node containing one of these pods, Kubernetes will refuse to evict it because doing so would leave only 4 pods running, violating your minAvailable: 4 constraint. The node will remain in a SchedulingDisabled state, and the pod will continue to run on it until you either manually delete the PDB, modify its constraints, or the pod is rescheduled elsewhere due to other events.
The one thing most people don’t realize is that PDBs only apply to voluntary disruptions. They offer no protection against involuntary disruptions like node failures, network partitions, or node reboots initiated outside of a graceful drain. If a node crashes, its pods are lost, PDB or not. The PDB’s role is to manage your control over the disruption process, not to magically keep pods alive against all odds.
The next concept you’ll likely explore is how PDBs interact with node upgrades managed by EKS managed node groups, and the implications for application availability during those automated processes.