Pod Disruption Budget (PDB)

A PDB only governs voluntary disruptions, which are initiated by cluster administrators or automated processes. These include:

• Draining a node for maintenance or upgrade.
• Deleting a pod managed by a Deployment.
• Updating a pod template that triggers a rolling update.

Involuntary disruptions, like a node hardware failure or a pod eviction due to resource exhaustion, are not blocked by a PDB. The budget's role is to ensure planned maintenance does not violate your application's availability requirements.

You define a PDB using one of two mutually exclusive fields:

• minAvailable: Specifies the absolute number or percentage of pods that must always be ready. For a 10-pod deployment, minAvailable: 80% (or 8) means the disruption process must never leave fewer than 8 pods running.
• maxUnavailable: Specifies the absolute number or percentage of pods that can be unavailable. For the same deployment, maxUnavailable: 20% (or 2) means the disruption process can take down up to 2 pods at a time.

These parameters create a budget of allowed concurrent disruptions, pacing the eviction process.

A PDB does not reference a Deployment or StatefulSet directly. Instead, it uses a label selector (spec.selector) to identify the pods it protects. This creates a loose coupling.

Example: A PDB with selector.matchLabels: app=api-server will apply to all pods with that label, whether they are managed by a Deployment, ReplicaSet, or StatefulSet. This is powerful for protecting logical application groups but requires careful label management to ensure the PDB matches the intended pod set.

When a cluster administrator runs kubectl drain <node>, the process interacts with PDBs:

1. The drain command identifies all pods on the node.
2. For each pod, it checks if eviction would violate any matching PDB.
3. Pods whose eviction is allowed are terminated. Pods whose eviction would violate the PDB are skipped, leaving the node in a draining but not fully cleared state.

The Kubernetes Eviction API respects PDBs, making this behavior consistent across all voluntary disruption tools.

A PDB's calculations are based on pods in the Ready state (as determined by their readiness probe). A pod that is running but failing its readiness probe is considered unavailable for the budget's purposes.

Critical Implication: If many pods are in a crash-loop or failing probes, they may already be counted as "unavailable." A voluntary disruption could then be blocked because the minAvailable threshold is already breached, even though no new pods are being deleted. Effective PDBs require stable pod health.

A core Kubernetes controller that ensures a specified number of identical pod replicas are running at any given time. It is the fundamental mechanism for maintaining desired scale and self-healing. A PDB works by placing constraints on the voluntary disruption of pods managed by a ReplicaSet or Deployment.

• Key Function: Continuously monitors pod count and creates/deletes pods to match the replicas field.
• Relation to PDB: The PDB's minAvailable or maxUnavailable settings are enforced against the pods this controller manages.

A Kubernetes controller that automatically scales the number of pods in a deployment or replica set based on observed metrics like CPU utilization or custom application metrics. It dynamically adjusts the replicas count on the ReplicaSet.

• Key Function: Enables applications to handle variable load by adding or removing pod instances.
• Interaction with PDB: During a scale-down event triggered by the HPA, the PDB policy is still enforced. The HPA cannot delete pods if doing so would violate the PDB's availability guarantees, ensuring scale-down operations do not compromise stability.

A kubectl command (kubectl drain <node-name>) that safely evicts all pods from a node in preparation for maintenance (e.g., kernel upgrade, node termination). It is the primary voluntary disruption that a PDB is designed to govern.

• Process: The drain command cordons the node (marks it unschedulable) and begins evicting pods. It respects Pod Disruption Budgets, waiting if eviction would violate the policy.
• PDB Enforcement: If draining a node would cause the number of available pods to fall below minAvailable or exceed maxUnavailable, the eviction API will return an error, and the drain command will wait, periodically retrying.

A critical distinction in Kubernetes availability management that defines the scope of a PDB's protection.

• Voluntary Disruptions: Initiated by the cluster operator or automated controllers. Examples include:
  • Draining a node for maintenance.
  • Deleting a pod managed by a Deployment.
  • A rolling update.
  • PDBs apply here.
• Involuntary Disruptions: Caused by unavoidable failures outside operator control. Examples include:
  • Hardware failure of the underlying physical machine.
  • Kernel panic.
  • Cloud provider preempting a virtual machine.
  • PDBs do NOT protect against these. For this, you rely on ReplicaSets and high replicas counts.

A higher-level Kubernetes abstraction that manages ReplicaSets and provides declarative updates for pods. It is the most common controller used with stateless applications.

• Key Function: Describes the desired state for pods and manages rolling updates and rollbacks.
• PDB Association: A PDB is typically applied to the pods created by a Deployment. During a rolling update, the Deployment controller coordinates pod creation and deletion, and these deletion actions are subject to the PDB's constraints. This ensures a controlled update pace that maintains application availability.

A periodic test performed by the kubelet on a container to determine if it is ready to accept network traffic. A pod is considered "ready" when all its containers' readiness probes pass.

• Key Function: Signals when a pod is fully initialized and operational, allowing it to be added to Service load balancers.
• Critical for PDBs: The PDB's calculation of "available" pods is based on pods with a status of Ready. If a pod's readiness probe fails, it is subtracted from the available count. Therefore, correctly configured readiness probes are essential for the PDB to accurately assess the health of the application and make correct eviction decisions.