Pod Disruption Budgets in Kubernetes - Deep Dive

Overview - Pod Disruption Budgets

What is it?

Pod Disruption Budgets (PDBs) are rules in Kubernetes that help keep your application running smoothly during planned changes. They tell Kubernetes how many pods of an application can be taken down at the same time without causing problems. This helps avoid downtime when you update or maintain your system. PDBs work by limiting voluntary disruptions like upgrades or manual pod deletions.

Why it matters

Without Pod Disruption Budgets, Kubernetes might stop too many pods at once during maintenance, causing your app to become unavailable or slow. This can frustrate users and hurt business. PDBs ensure your app stays reliable and responsive even when changes happen, making your system trustworthy and professional.

Where it fits

Before learning PDBs, you should understand basic Kubernetes concepts like pods, deployments, and how Kubernetes manages pod lifecycle. After mastering PDBs, you can explore advanced topics like cluster autoscaling, node draining, and high availability strategies.

Mental Model

Core Idea

Pod Disruption Budgets set safe limits on how many pods can be down at once to keep your app stable during planned changes.

Think of it like...

Imagine a restaurant with several chefs (pods). PDBs are like a rule that says only a certain number of chefs can take a break at the same time so the kitchen keeps running smoothly.

┌───────────────────────────────┐
│       Kubernetes Cluster       │
│ ┌───────────────┐             │
│ │ Pod Disruption│             │
│ │ Budget (PDB)  │             │
│ └──────┬────────┘             │
│        │ Limits max pods down  │
│        ▼                      │
│ ┌───────────────┐             │
│ │ Pods (App)    │◄────────────┤
│ │ ┌───┐ ┌───┐ ┌───┐ │          │
│ │ │   │ │   │ │   │ │          │
│ │ └───┘ └───┘ └───┘ │          │
│ └───────────────┘             │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is a Pod in Kubernetes

Concept: Introduce the basic unit of deployment in Kubernetes called a pod.

A pod is the smallest unit that runs your application in Kubernetes. It can hold one or more containers that share storage and network. Pods are created and managed by Kubernetes to run your app code.

Result

You understand that pods are the building blocks of apps in Kubernetes.

Knowing what pods are is essential because PDBs control how pods are disrupted during maintenance.

2

Foundation

Understanding Pod Lifecycle and Disruptions

Concept: Explain how pods can be stopped or restarted and what disruptions mean.

Pods can stop running for many reasons: crashes, updates, or manual deletion. Disruptions are events that cause pods to stop temporarily. Kubernetes handles some disruptions automatically (like crashes) and others are voluntary (like upgrades).

Result

You see that pods can be disrupted voluntarily or involuntarily, affecting app availability.

Distinguishing voluntary disruptions is key because PDBs only control these to keep apps stable.

3

Intermediate

Introducing Pod Disruption Budgets

🤔Before reading on: do you think PDBs control all pod failures or only some? Commit to your answer.

Concept: PDBs limit voluntary disruptions to pods to keep enough pods running during planned changes.

A Pod Disruption Budget is a Kubernetes object that sets rules like 'at least 2 pods must be running' or 'no more than 1 pod can be down' during voluntary disruptions. This helps avoid too many pods stopping at once.

Result

You can define a PDB to protect your app from too many pods being disrupted simultaneously.

Understanding that PDBs only limit voluntary disruptions helps you plan maintenance without risking downtime.

4

Intermediate

How to Define a Pod Disruption Budget

🤔Before reading on: do you think PDBs use exact pod counts or percentages? Commit to your answer.

Concept: Learn the syntax and options to create a PDB using minimum available pods or maximum unavailable pods.

A PDB YAML includes selectors to match pods and a field like 'minAvailable' or 'maxUnavailable'. For example: apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: myapp-pdb spec: minAvailable: 2 selector: matchLabels: app: myapp This means at least 2 pods must be running during disruptions.

Result

You can write and apply a PDB manifest to your Kubernetes cluster.

Knowing both minAvailable and maxUnavailable options lets you flexibly control pod disruptions.

5

Intermediate

PDB Behavior During Node Drains and Upgrades

🤔Before reading on: do you think Kubernetes always respects PDBs during node drains? Commit to your answer.

Concept: Understand how PDBs interact with node maintenance and how Kubernetes enforces them.

When you drain a node (remove it for maintenance), Kubernetes tries to evict pods safely. It checks PDBs to avoid evicting too many pods at once. If evicting a pod would break the PDB, Kubernetes waits or fails the eviction.

Result

You see that PDBs protect app availability during node maintenance.

Knowing that PDBs can block evictions helps you plan maintenance carefully to avoid stuck pods.

6

Advanced

Limitations and Edge Cases of Pod Disruption Budgets

🤔Before reading on: do you think PDBs protect against pod crashes? Commit to your answer.

Concept: Explore what PDBs do NOT protect against and common pitfalls.

PDBs only control voluntary disruptions, not involuntary ones like pod crashes or node failures. Also, if your app has fewer pods than the PDB minimum, Kubernetes may block all disruptions. Misconfigured PDBs can cause stuck pods during upgrades.

Result

You understand PDB limits and how to avoid common mistakes.

Knowing PDB boundaries prevents downtime caused by misunderstanding their scope.

7

Expert

Advanced PDB Usage in Production Clusters

🤔Before reading on: do you think multiple PDBs can apply to the same pod? Commit to your answer.

Concept: Learn how to use multiple PDBs, combine with other policies, and handle complex scenarios.

In large clusters, multiple PDBs can target overlapping pods, and Kubernetes enforces all of them. Combining PDBs with Pod Priority and Preemption helps manage disruptions during high load. Experts also monitor PDB status to detect blocked evictions and automate remediation.

Result

You can design robust disruption policies for complex production environments.

Understanding multi-PDB interactions and integration with priorities is key for high-availability systems.

Under the Hood

Kubernetes tracks pod disruptions through the eviction API. When a voluntary disruption is requested, Kubernetes checks the PDB associated with the pod's labels. It counts how many pods are currently available and compares with the PDB's minAvailable or maxUnavailable. If evicting a pod would violate the PDB, the eviction is blocked until pods become available again. This coordination happens via the Kubernetes control plane and the API server.

Why designed this way?

PDBs were designed to give cluster operators control over planned disruptions without interfering with automatic recovery from failures. This separation allows Kubernetes to maintain high availability while still enabling maintenance. Alternatives like manual pod management were error-prone and caused downtime, so PDBs automate safe disruption limits.

┌───────────────────────────────┐
│       Kubernetes Control Plane │
│ ┌───────────────┐             │
│ │ Eviction API  │◄────────────┤
│ └──────┬────────┘             │
│        │ Checks PDB rules      │
│        ▼                      │
│ ┌───────────────┐             │
│ │ Pod Disruption│             │
│ │ Budget (PDB)  │             │
│ └──────┬────────┘             │
│        │ Allows or blocks      │
│        ▼                      │
│ ┌───────────────┐             │
│ │ Pod Eviction  │             │
│ └───────────────┘             │
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do PDBs prevent pods from crashing unexpectedly? Commit to yes or no.

Common Belief: PDBs protect pods from all types of disruptions, including crashes and hardware failures.

Reality: PDBs only limit voluntary disruptions like manual deletions or node drains; they do not prevent involuntary failures like crashes.

Why it matters: Believing PDBs protect against crashes can lead to overconfidence and lack of proper monitoring or redundancy, causing unexpected downtime.

Quick: Can a PDB require more pods than actually exist? Commit to yes or no.

Common Belief: You can set any number in minAvailable, even if you have fewer pods than that number.

Reality: If minAvailable is higher than the number of pods, Kubernetes will block all voluntary disruptions, causing maintenance to stall.

Why it matters: Misconfiguring PDBs this way can cause stuck pods and prevent updates or scaling.

Quick: Do multiple PDBs on the same pod combine or override each other? Commit to combine or override.

Common Belief: Only one PDB applies per pod; others are ignored.

Reality: Multiple PDBs can apply to the same pod, and all must be satisfied for eviction to proceed.

Why it matters: Ignoring this can cause unexpected eviction blocks and complex debugging.

Quick: Does Kubernetes always respect PDBs during node drains? Commit to yes or no.

Common Belief: Kubernetes will always wait to respect PDBs before evicting pods during node drains.

Reality: In some cases, like forced node deletion or emergency, Kubernetes may bypass PDBs to maintain cluster health.

Why it matters: Assuming absolute enforcement can lead to surprises during emergency operations.

Expert Zone

1

PDBs only count pods matching the selector and in Ready state, so transient pod readiness affects disruption allowance.

2

Evictions blocked by PDBs can cause node drains to hang, requiring manual intervention or timeout configurations.

3

Combining PDBs with Pod Priority and Preemption allows graceful handling of critical pods during resource pressure.

When NOT to use

Avoid using PDBs for applications with very few pods or stateless workloads where downtime is acceptable. Instead, rely on replication and fast recovery. For involuntary disruptions like crashes, use readiness probes and auto-healing mechanisms.

Production Patterns

In production, teams create PDBs per application tier to ensure minimum availability during rolling updates. They monitor PDB status via metrics and alerts to detect blocked evictions. Advanced setups combine PDBs with Pod Priority to protect critical services and automate node maintenance with disruption-aware tooling.

Connections

Load Balancing

PDBs ensure enough pods are available to receive traffic, which complements load balancing strategies.

Understanding PDBs helps ensure load balancers always have healthy pods to route traffic to, preventing user-facing errors.

Circuit Breaker Pattern (Software Design)

Both PDBs and circuit breakers aim to maintain system stability by limiting failure impact.

Knowing PDBs as a form of failure containment helps grasp how circuit breakers prevent cascading failures in software.

Workforce Shift Scheduling

PDBs are like scheduling rules that limit how many workers can be off at once to keep operations running.

This cross-domain link shows how managing availability in teams parallels managing pod availability in clusters.

Common Pitfalls

#1 Setting minAvailable higher than the number of pods.

Wrong approach:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: wrong-pdb
spec:
minAvailable: 5
selector:
matchLabels:
app: smallapp

Correct approach:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: correct-pdb
spec:
minAvailable: 1
selector:
matchLabels:
app: smallapp

Root cause:

Misunderstanding that minAvailable must not exceed the actual pod count causes maintenance to block indefinitely.

#2 Expecting PDBs to prevent pod crashes or node failures.

Wrong approach:

Relying solely on PDBs for high availability without readiness probes or auto-healing.

Correct approach:

Use readiness probes, liveness probes, and auto-healing controllers alongside PDBs.

Root cause:

Confusing voluntary disruption control with failure recovery leads to fragile systems.

#3 Ignoring multiple PDBs applying to the same pods.

Wrong approach:

Creating overlapping PDBs without coordination, expecting only one to apply.

Correct approach:

Design PDBs carefully so combined rules do not block evictions unexpectedly.

Root cause:

Lack of awareness that Kubernetes enforces all matching PDBs causes unexpected eviction failures.

Key Takeaways

Pod Disruption Budgets protect your app by limiting how many pods can be voluntarily disrupted at once.

They only control planned disruptions, not unexpected pod crashes or node failures.

PDBs use minAvailable or maxUnavailable to define safe disruption limits based on pod counts or percentages.

Misconfiguring PDBs can block maintenance or cause downtime, so careful planning is essential.

In production, PDBs combine with other Kubernetes features like Pod Priority to ensure high availability during updates.

Practice

1. What is the main purpose of a Pod Disruption Budget in Kubernetes?

easy

A. To ensure a minimum number of pods stay available during planned disruptions

B. To automatically restart pods when they crash

C. To scale pods up or down based on CPU usage

D. To backup pod data before deletion

Solution

1. Step 1: Understand Pod Disruption Budget purpose

   A Pod Disruption Budget (PDB) is designed to keep your app available during planned changes by limiting voluntary disruptions.

2. Step 2: Match purpose to options

   To ensure a minimum number of pods stay available during planned disruptions correctly states that PDB ensures a minimum number of pods remain running during disruptions, unlike other options which describe unrelated features.

3. Final Answer:

   To ensure a minimum number of pods stay available during planned disruptions -> Option A

4. Quick Check:

   Pod Disruption Budget = availability during disruptions [OK]

Hint: PDB = minimum pods running during planned changes [OK]

Common Mistakes:

• Confusing PDB with auto-scaling
• Thinking PDB restarts crashed pods
• Assuming PDB backs up pod data

2. Which of the following is the correct way to specify a Pod Disruption Budget that allows at most 1 pod disruption at a time for pods with label app=web?

easy

A. apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: pdb-web
spec:
maxUnavailable: 1
selector:
matchLabels:
app: web
minReadySeconds: 10

B. apiVersion: v1
kind: PodDisruptionBudget
metadata:
name: pdb-web
spec:
minAvailable: 1
selector:
matchLabels:
app: web

C. apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: pdb-web
spec:
maxUnavailable: 1
selector:
matchLabels:
app: web
strategy: RollingUpdate

D. apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: pdb-web
spec:
maxUnavailable: 1
selector:
matchLabels:
app: web

Solution

1. Step 1: Check API version and kind

   The correct API version for PDB is policy/v1 and kind is PodDisruptionBudget.

2. Step 2: Validate spec fields for maxUnavailable and selector

   apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: pdb-web spec: maxUnavailable: 1 selector: matchLabels: app: web correctly uses maxUnavailable: 1 and a selector matching label app: web. Other options either use wrong API version, extra unsupported fields, or wrong spec keys.

3. Final Answer:

   apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: pdb-web spec: maxUnavailable: 1 selector: matchLabels: app: web -> Option D

4. Quick Check:

   Correct API and maxUnavailable syntax = apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: pdb-web spec: maxUnavailable: 1 selector: matchLabels: app: web [OK]

Hint: Use policy/v1 and maxUnavailable with correct selector [OK]

Common Mistakes:

• Using wrong API version like v1
• Adding unsupported fields like strategy
• Confusing minAvailable with maxUnavailable

3. Given this Pod Disruption Budget YAML snippet:

spec:
  minAvailable: 3
  selector:
    matchLabels:
      app: backend

If there are 5 pods with label app=backend, how many pods can be disrupted at once without violating the PDB?

medium

A. 3 pods

B. 2 pods

C. 5 pods

D. 0 pods

Solution

1. Step 1: Understand minAvailable meaning

   minAvailable: 3 means at least 3 pods must stay running during disruptions.

2. Step 2: Calculate allowed disruptions

   With 5 pods total, maximum disruptions allowed = 5 - 3 = 2 pods.

3. Final Answer:

   2 pods -> Option B

4. Quick Check:

   5 total - 3 minAvailable = 2 allowed disruptions [OK]

Hint: Allowed disruptions = total pods - minAvailable [OK]

Common Mistakes:

• Confusing minAvailable with maxUnavailable
• Assuming all pods can be disrupted
• Ignoring total pod count

4. You applied this Pod Disruption Budget:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-db
spec:
  maxUnavailable: 2
  selector:
    matchLabels:
      app: database

But Kubernetes reports an error: "spec.maxUnavailable: Invalid value: "2": must be less than the number of pods selected by the label selector". What is the likely cause?

medium

A. There are fewer than 3 pods with label app=database

B. maxUnavailable must be a percentage, not a number

C. The selector label is incorrect syntax

D. PodDisruptionBudget requires minAvailable, not maxUnavailable

Solution

1. Step 1: Understand maxUnavailable validation

   maxUnavailable must be less than the total number of pods matched by the selector.

2. Step 2: Analyze error message meaning

   The error says "must be less than the number of pods" meaning the number of pods with label app=database is less than or equal to 2.

3. Final Answer:

   There are fewer than 3 pods with label app=database -> Option A

4. Quick Check:

   maxUnavailable < total pods = error if not [OK]

Hint: maxUnavailable must be less than pod count [OK]

Common Mistakes:

• Using maxUnavailable as percentage incorrectly
• Miswriting selector labels
• Thinking minAvailable is mandatory

5. You have a deployment with 10 pods labeled app=frontend. You want to ensure that during voluntary disruptions, at least 80% of pods remain available. Which Pod Disruption Budget spec is correct?

hard

A. spec:
minAvailable: 80
selector:
matchLabels:
app: frontend

B. spec:
maxUnavailable: 8
selector:
matchLabels:
app: frontend

C. spec:
maxUnavailable: 20%
selector:
matchLabels:
app: frontend

D. spec:
minAvailable: 20%
selector:
matchLabels:
app: frontend

Solution

1. Step 1: Understand percentage usage in PDB

   maxUnavailable and minAvailable can accept percentages. To keep 80% available, maxUnavailable should be 20%.

2. Step 2: Evaluate options for correctness

   spec: minAvailable: 80 selector: matchLabels: app: frontend: minAvailable: 80 - absolute value exceeds total pods (10) - invalid.
   spec: maxUnavailable: 8 selector: matchLabels: app: frontend: maxUnavailable: 8 - allows 8 pods unavailable (only 20% available) - insufficient.
   spec: maxUnavailable: 20% selector: matchLabels: app: frontend: maxUnavailable: 20% - allows 20% (~2 pods) unavailable - ensures 80% available - correct.
   spec: minAvailable: 20% selector: matchLabels: app: frontend: minAvailable: 20% - ensures only at least 20% available - insufficient.

3. Final Answer:

   spec: maxUnavailable: 20% selector: matchLabels: app: frontend -> Option C

4. Quick Check:

   20% maxUnavailable = 80% pods available [OK]

Hint: Use maxUnavailable: 20% to keep 80% pods up [OK]

Common Mistakes:

• Using minAvailable with percentage incorrectly
• Confusing absolute numbers with percentages
• Not matching selector labels properly