#Using PodDisruptionBudgets

#Understanding PodDisruptionBudgets

Refer to the official Kubernetes documentation: Specifying a Disruption Budget for your Application

A PodDisruptionBudget (PDB) allows you to limit the disruption to your application when its pods need to be rescheduled for some reason such as upgrades or routine maintenance work on the Kubernetes nodes.

As a cluster administrator or application owner, you can create a PodDisruptionBudget for each application. A PDB limits the number of Pods of a replicated application that are down simultaneously from voluntary disruptions. For example, a quorum-based application would like to ensure that the number of replicas running is never brought below the number needed for a quorum. A web front end might want to ensure that the number of replicas serving load never falls below a certain percentage of the total.

By using PodDisruptionBudgets, you can:

• Ensure High Availability: Maintain a minimum number of available replicas during node maintenance, cluster upgrades, or other voluntary disruptions.
• Control Disruption Impact: Define exactly how much disruption an application can tolerate by specifying minAvailable or maxUnavailable.
• Safely Drain Nodes: During operations like kubectl drain, the system respects PDBs and waits until Pods can be safely evicted without violating the disruption budget.

How it works:

1. You define a PodDisruptionBudget resource targeting a specific set of Pods using a label selector.
2. You specify either minAvailable (minimum number or percentage of Pods that must remain available) or maxUnavailable (maximum number or percentage of Pods that can be concurrently unavailable).
3. When a voluntary disruption occurs (like draining a node for an OS upgrade), the eviction API checks the PDB. If evicting the Pod would violate the budget, the eviction is blocked or delayed until enough Pods are available again.

#Creating PodDisruptionBudgets

#Creating a PDB by using CLI

#Prerequisites

• Ensure you have kubectl configured and connected to your cluster.
• You must have an application running with multiple replicas (like a Deployment or StatefulSet).

#YAML file example

# example-pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 2 # Alternatively, you can use maxUnavailable: 1
  selector:
    matchLabels:
      app: nginx

#Creating a PDB via YAML

# Step 1: Create the PodDisruptionBudget
kubectl apply -f example-pdb.yaml

# Step 2: Verify the PDB status
kubectl get pdb nginx-pdb

The output will show the allowed disruptions, minimum available, and current healthy pods.

#Managing a PDB by using CLI

#Viewing a PDB

• List all PDBs in a namespace:

  kubectl get poddisruptionbudgets

• Get detailed information about a specific PDB:

  kubectl describe poddisruptionbudget <pdb-name>

#Updating a PDB

You can update a PDB by editing its configuration. For instance, to change minAvailable:

kubectl edit poddisruptionbudget <pdb-name>

Modify the minAvailable or maxUnavailable fields, save, and exit.

#Deleting a PDB

If you no longer need to protect the workload with a PDB, you can safely delete it:

kubectl delete poddisruptionbudget <pdb-name>

Deleting the PDB will not affect the actual running application, it only removes the disruption budget constraints for node maintenance and eviction processes.

#When to use a PodDisruptionBudget

You should consider using a PDB when:

• Your application requires a strict minimum number of replicas to handle traffic or maintain quorum (e.g., ZooKeeper, Elasticsearch).
• You are running workloads on a cluster where cluster administrators frequently perform node upgrades or scaling operations.
• You want to ensure zero-downtime during voluntary disruptions such as node drains.

A PDB is NOT helpful for involuntary disruptions (e.g., node hardware failure, kernel panic), as those cannot be delayed or prevented by Kubernetes.