In this lesson, you will learn how to use Pod Disruption Budgets (PDBs) to guarantee high availability for your applications during voluntary maintenance events like node upgrades or cluster scaling.
Understanding Voluntary vs. Involuntary Disruptions
In Kubernetes, disruptions fall into two categories: involuntary and voluntary. Involuntary disruptions (like hardware failure or kernel panics) are unavoidable. Voluntary disruptions, however, are initiated by cluster administrators to perform maintenance, such as draining a node to patch the OS or upgrading the Kubernetes control plane. Without guardrails, a cluster administrator might accidentally drain nodes too quickly, causing all your application replicas to go offline simultaneously.
The Role of Pod Disruption Budgets
A PodDisruptionBudget acts as a safety contract between your application and the cluster administrator. It informs the Kubernetes eviction API about how many replicas must stay running at any given time. If an administrator attempts to perform a voluntary action that would violate this budget, the API server will reject the request until enough pods are available elsewhere.
Defining the Budget
You define a PDB by specifying a selector to target your application and either a minAvailable count or a maxUnavailable percentage.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-app-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: frontend
In this example, the controller ensures that at least two pods labeled app: frontend are always running. If you have three replicas, this configuration allows only one pod to be down at a time during maintenance. If you only had two replicas, Kubernetes would block any eviction until a new replica is successfully scheduled and ready on another node.
By setting these constraints, you ensure that your services remain resilient even when the underlying infrastructure is being actively modified. This is especially vital for stateful workloads or high-traffic services where even a few minutes of downtime can impact business operations.
Key Takeaway: A Pod Disruption Budget prevents cluster administrators from accidentally taking down your entire application by enforcing a strict minimum availability threshold during voluntary maintenance events.