Pod Disruption Budget (PDB)

A PDB only governs voluntary disruptions, which are initiated by cluster administrators or automated systems with the intent of maintaining the cluster. These include:

• Node drain operations for maintenance or scaling.
• Deployment updates that trigger pod eviction.
• Cluster autoscaler removing an underutilized node.

It does not protect against involuntary disruptions, such as:

• Hardware failure of a node.
• The Linux kernel Out-of-Memory (OOM) Killer terminating a pod.
• A cloud provider deleting the underlying VM. For involuntary failures, high availability is achieved through replica counts and other cluster-level resilience patterns.

A PDB specifies constraints using one of two mutually exclusive fields, defining the disruption budget in absolute numbers or percentages:

• minAvailable: Specifies the minimum number (e.g., 2) or percentage (e.g., "50%") of pods from the controlled set that must remain available during a disruption. This is useful for ensuring a baseline service capacity.

• maxUnavailable: Specifies the maximum number (e.g., 1) or percentage (e.g., "25%") of pods from the controlled set that can be unavailable simultaneously. This is often used for applications where any downtime is critical.

For a deployment with 4 replicas, a maxUnavailable: 1 ensures at least 3 pods are always running, while a minAvailable: "75%" achieves the same constraint.

A PDB does not reference pods directly. Instead, it uses a label selector (spec.selector) to dynamically match a set of pods. This selector must match the labels on the pods managed by a Deployment, StatefulSet, or other workload controller.

Example: A PDB with selector.matchLabels: app=api-server will apply to all pods with the label app: api-server. This decouples the availability policy from the specific pod instances, allowing the PDB to work seamlessly as pods are created and deleted by the workload controller during normal operations and scaling events.

The Kubernetes cluster autoscaler and the kubectl drain command explicitly respect PDBs. When a user requests a node drain, the system:

1. Checks all PDBs to see if evicting pods from the node would violate any constraints.
2. If allowed, it evicts pods gracefully, respecting the pod's terminationGracePeriodSeconds.
3. If a violation would occur, the drain command blocks and fails by default. The --disable-eviction flag or a PodDisruptionBudget with maxUnavailable: 0 can create an intentional operational gate, requiring manual intervention to proceed.

A PDB's status field provides real-time observability into its enforcement:

• currentHealthy: The number of currently observed healthy pods matching the selector.
• desiredHealthy: The minimum number of pods required to be healthy, derived from minAvailable or maxUnavailable.
• disruptionsAllowed: The number of pods that can currently be disrupted without violating the budget. This is the key operational metric.
• expectedPods: The total number of pods matched by the selector.

Monitoring disruptionsAllowed dropping to 0 is critical, as it signals that voluntary disruptions are blocked, potentially halting automated cluster operations.

PDBs are a core component of a layered resilience strategy and interact with several sibling fault-tolerance concepts:

• Circuit Breaker Pattern: While a circuit breaker protects a service from downstream failures, a PDB protects the service's own instances from being removed. They are complementary controls.
• Graceful Degradation: A PDB enforcing minAvailable: "50%" ensures the service degrades gracefully under operational pressure, maintaining partial capacity.
• Canary Deployment: During a canary rollout, a PDB on the stable deployment can prevent too many of its pods from being replaced simultaneously, ensuring the canary handles only a defined fraction of traffic.
• Health Probes: PDBs consider a pod "healthy" if it is in the Ready condition, which is determined by the pod's readiness probe. Properly configured probes are essential for PDB accuracy.

PDBs are essential for stateful applications like databases (e.g., PostgreSQL, Cassandra) and message queues (e.g., Kafka). These systems often have complex replication and leader-follower topologies where losing multiple pods simultaneously can cause data loss or extended unavailability.

• Example: A 3-pod Kafka cluster with a PDB of maxUnavailable: 1. This ensures the cluster maintains a quorum (2 out of 3 brokers) during voluntary disruptions, preventing a complete loss of message production or consumption.
• Key Consideration: The PDB minAvailable or maxUnavailable value must align with the application's own replication factor and quorum requirements.

During planned node maintenance (e.g., kernel updates, hardware refresh), the Kubernetes scheduler uses PDBs to safely drain nodes. The drain command will evict pods, but it respects PDB constraints, cordoning the node and waiting if evicting pods would violate the budget.

• Process: 1) Administrator initiates kubectl drain <node-name>. 2) The API server checks PDBs for pods on the node. 3) If eviction violates a PDB, the drain is blocked until the condition is resolved (e.g., by manually scaling up the deployment).
• Result: This allows for zero-downtime maintenance windows for applications that define appropriate PDBs, transforming a risky operation into a predictable, automated procedure.

PDBs work in tandem with deployment strategies to prevent self-inflicted outages. During a rolling update of a Deployment, Kubernetes creates new pods and terminates old ones. A PDB ensures the rollout does not proceed too aggressively.

• Scenario: A Deployment with 10 replicas and a PDB of minAvailable: 8. The rolling update will never have fewer than 8 ready pods serving traffic. The controller will terminate an old pod, wait for its replacement to become Ready, and only then proceed to terminate the next one.
• Integration: This is a form of automated rollback strategy. If the new pods fail their health checks, the update stalls, preserving the minimum available pods from the old version.

For stateless microservices, a PDB defines the service's availability SLA to the cluster. It acts as a declarative guardrail against excessive pod churn, ensuring a baseline level of capacity for handling incoming requests.

• Example: A frontend API service with 5 replicas might have a PDB of maxUnavailable: 20%. This guarantees at least 4 pods are always available, allowing the cluster autoscaler or other controllers to voluntarily disrupt only one pod at a time.
• Benefit: This prevents thundering herd scenarios where multiple pods are simultaneously evicted from a node under pressure, which could cascade latency spikes or errors through the dependency graph.

The Cluster Autoscaler uses PDBs when deciding to scale down a node. A node is only considered for removal if all pods running on it can be safely moved elsewhere without violating any PDB.

• Cost Optimization: This allows for aggressive cluster scaling policies while protecting application availability. Without PDBs, the autoscaler might remove a node hosting multiple pods from the same application, causing an unintended outage.
• Constraint: Pods with restrictive PDBs (e.g., minAvailable set to a high percentage of total replicas) can block scale-down operations, potentially increasing cloud costs. The PDB value is a direct trade-off between resilience and resource efficiency.

It is critical to understand that a PDB only governs voluntary disruptions. These are disruptions initiated by the cluster controllers (human or automated). It provides no protection against involuntary disruptions.

• Voluntary Disruptions: Node drain, eviction by cluster autoscaler, deletion of a pod by a Deployment controller.
• Involuntary Disruptions: Hardware failure, kernel panic, node running out of resources (triggering the OOM Killer), or a provider deleting the underlying VM.
• Implication: A PDB is not a substitute for overall high-availability design. It must be complemented by:
  • Adequate pod replicas spread across failure domains (using Pod Anti-Affinity).
  • Robust health probes (liveness/readiness).
  • Resource requests and limits to prevent OOM kills.

The core control mechanism in declarative systems like Kubernetes. It continuously observes the actual state of the system, compares it to the declared desired state (e.g., a Deployment spec), and executes actions to converge the two.

• Observe: Scan the current state of pods, nodes, etc.
• Diff: Compare against the desired state in the API server.
• Act: Create, delete, or update objects to eliminate the difference.

The PDB is a constraint evaluated within this loop. The scheduler and disruption controllers respect the PDB's maxUnavailable or minAvailable rules when planning reconciliation actions that involve pod termination.

A design philosophy where a system maintains limited functionality during partial failures, ensuring a basic level of service instead of a complete outage.

• Prioritizes Critical Paths: Core user journeys remain operational while non-essential features are temporarily disabled.
• Informs PDB Configuration: Helps determine the acceptable maxUnavailable percentage. For example, a read-only mode might be acceptable if 40% of pods are down, guiding a PDB setting of maxUnavailable: 40%.

This concept directly informs the business-level decisions that technical PDB configurations are meant to enforce.