Pod Disruption Budget

Kubernetes Pod Disruption Budget Practical Guide

Have you ever faced a situation where your application suddenly went down during a cluster upgrade or scaling event? Frustrating, right?

Losing pods at the wrong moment can mean downtime, unhappy users, and stress all around. Well, here’s where Pod Disruption Budgets (PDB) step in to save the day.

What Exactly is a Pod Disruption Budget (PDB)?

A PDB makes sure that during voluntary disruptions (like a node drain) or involuntary events (like a node crash), a certain number of pods remain running. Without it, Kubernetes could easily kill off too many pods at once, leaving your service unavailable.

What Happens Without a PDB?

Imagine this: you’ve got 3 nodes, and your app is running 2 pods—App 1 on Node 1 and App 2 on Node 2. When Node 1 gets drained, App 1 is terminated, but App 3 is still pending and hasn’t started on Node 3 yet.

Now, if Node 2 gets drained while App 3 is still pending, App 2 is terminated as well. What are you left with? No healthy pods. Your service is down until the new pod is up.

What Happens With a PDB?

If you configure a PDB requiring that at least 1 pod must be running, this changes everything. When Node 1 is drained and App 1 terminates, App 3 starts getting ready. But if the system tries to drain Node 2 before App 3 is running, Kubernetes will block the drain to keep App 2 alive. This way, you’ll never be left without healthy pods, ensuring continuous service.

How to Implement a Pod Disruption Budget ?

Let’s set up a techopsexamples deployment with 6 replicas and a PDB to ensure that at least 3 pods remain available during any disruption.

Step 1: Create the Deployment

apiVersion: apps/v1

kind: Deployment

metadata:

name: teg-app

namespace: production

spec:

replicas: 6

selector:

matchLabels:

app: teg

template:

metadata:

labels:

app: teg

spec:

containers:

- name: teg-container

image: teg-app:v1.0

Apply the deployment:

kubectl apply -f teg-deployment.yaml

Check your pods:

kubectl get pods

You should see something like:

NAME READY STATUS

teg-app-6d9fc4fc8b-xyz 1/1 Running

teg-app-6d9fc4fc8b-abc 1/1 Running

Step 2: Create the PDB

Lets, create a PDB to ensure at least 3 pods are always available:

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

name: teg-pdb

namespace: production

spec:

minAvailable: 3

selector:

matchLabels:

app: teg

Apply the PDB:

kubectl apply -f teg-pdb.yaml

Check the PDB:

kubectl get poddisruptionbudgets

You should see something like:

NAME MIN AVAILABLE ALLOWED DISRUPTIONS AGE

teg-pdb 3 3 30s

Step 3: Test the PDB by Draining a Node

Now simulate a disruption by draining a node:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data