Pod Disruption Budgets in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Pod Disruption Budget Purpose

What is the primary purpose of a Pod Disruption Budget (PDB) in Kubernetes?

A To define resource limits for pods

B To limit the number of pods that can be voluntarily disrupted at the same time

C To scale pods up or down based on CPU usage

D To automatically restart pods when they crash

💡 Hint

Think about how Kubernetes manages pod availability during maintenance or upgrades.

A Pod Disruption Budget ensures that voluntary disruptions like node drains or upgrades do not reduce the number of available pods below a certain threshold.

💻 Command Output

intermediate

PDB Status After Node Drain

Given this Pod Disruption Budget YAML:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Assuming 3 pods labeled app=myapp are running, what will be the status of the PDB after draining a node hosting 2 pods?

A DisruptionsAllowed: 1, CurrentHealthy: 2, DesiredHealthy: 2

B DisruptionsAllowed: 2, CurrentHealthy: 3, DesiredHealthy: 2

C DisruptionsAllowed: 0, CurrentHealthy: 1, DesiredHealthy: 2

D DisruptionsAllowed: 0, CurrentHealthy: 3, DesiredHealthy: 2

💡 Hint

Consider how many pods remain healthy after removing 2 pods from 3 total.

With 3 pods and minAvailable 2, draining 2 pods leaves only 1 healthy pod, which is below the minimum. So disruptions allowed is 0.

❓ Configuration

advanced

Correct PDB YAML for MaxUnavailable

Which YAML snippet correctly defines a Pod Disruption Budget that allows at most 1 pod to be unavailable at any time for pods labeled app=web?

A

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

B

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

C

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  maxUnavailable: "one"
  selector:
    matchLabels:
      app: web

D

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

💡 Hint

Check the correct field name and value type for limiting unavailable pods.

maxUnavailable: 1 correctly limits disruptions to 1 pod. Option A uses minAvailable which is different. Option A uses invalid string value. Option A allows 2 pods unavailable, not 1.

❓ Troubleshoot

advanced

Why is PDB Not Blocking Pod Eviction?

You created a Pod Disruption Budget with minAvailable: 3 for pods labeled app=api. There are 5 pods running. However, when you drain a node hosting 3 pods, Kubernetes allows eviction and the pods terminate. Why?

A The pods are not managed by a controller, so PDB is ignored

B minAvailable must be less than total pods, so 3 is invalid here

C PDB only works for involuntary disruptions, not node drains

D The PDB selector does not match the pods because labels differ

💡 Hint

Check if the PDB selector matches the pods exactly.

If the selector does not match pods, the PDB does not apply, so evictions proceed without blocking.

🔀 Workflow

expert

Sequence to Safely Upgrade Nodes with PDB

Arrange the steps in the correct order to safely upgrade Kubernetes nodes without violating Pod Disruption Budgets for a deployment with 4 replicas and minAvailable: 3.

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

Think about preventing new pods, safely evicting existing pods, upgrading, then reopening the node.

First cordon to stop new pods, then drain to evict pods respecting PDB, upgrade node, then uncordon to allow pods again.