Pod Disruption Budgets in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the minimum number of pods that must be available during disruptions.

Kubernetes

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: [1]
  selector:
    matchLabels:
      app: myapp

Drag options to blanks, or click blank then click option'

A1

B3

C0

D5

Attempts:

3 left

💡 Hint

Common Mistakes

Setting minAvailable to 0 allows all pods to be disrupted, which defeats the purpose.

Using a number larger than the total pods causes errors.

The minAvailable field sets the minimum number of pods that must be up during disruptions. Here, '1' means at least one pod stays running.

2fill in blank

medium

Complete the code to select pods with label 'app: frontend' for the Pod Disruption Budget.

Kubernetes

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: frontend-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: [1]

Drag options to blanks, or click blank then click option'

Abackend

Bcache

Cdatabase

Dfrontend

Attempts:

3 left

💡 Hint

Common Mistakes

Using the wrong label value will select the wrong pods or none at all.

Misspelling the label key or value causes no pods to match.

The selector.matchLabels field filters pods by their labels. Here, 'frontend' selects pods labeled with app=frontend.

3fill in blank

hard

Fix the error in the Pod Disruption Budget by completing the missing field for maximum allowed disruptions.

Kubernetes

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: db-pdb
spec:
  [1]: 1
  selector:
    matchLabels:
      app: database

Drag options to blanks, or click blank then click option'

AmaxUnavailable

BminAvailable

CmaxAvailable

DminUnavailable

Attempts:

3 left

💡 Hint

Common Mistakes

Using both minAvailable and maxUnavailable together causes validation errors.

Using incorrect field names like maxAvailable or minUnavailable.

The maxUnavailable field sets the maximum number of pods that can be down during disruptions. It is an alternative to minAvailable.

4fill in blank

hard

Fill both blanks to create a Pod Disruption Budget that allows at most 2 pods to be unavailable and selects pods labeled 'tier: frontend'.

Kubernetes

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: frontend-pdb
spec:
  [1]: 2
  selector:
    matchLabels:
      tier: [2]

Drag options to blanks, or click blank then click option'

AmaxUnavailable

BminAvailable

Cfrontend

Dbackend

Attempts:

3 left

💡 Hint

Common Mistakes

Confusing minAvailable with maxUnavailable.

Selecting the wrong label value causes no pods to be matched.

Using maxUnavailable: 2 allows up to two pods to be down. The selector chooses pods with label tier=frontend.

5fill in blank

hard

Fill all three blanks to create a Pod Disruption Budget that requires at least 3 pods available, selects pods labeled 'component: api', and uses the correct API version.

Kubernetes

apiVersion: [1]
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  [2]: 3
  selector:
    matchLabels:
      component: [3]

Drag options to blanks, or click blank then click option'

Apolicy/v1beta1

BminAvailable

Capi

Dpolicy/v1

Attempts:

3 left

💡 Hint

Common Mistakes

Using deprecated API versions like policy/v1beta1.

Mixing up minAvailable and maxUnavailable.

Incorrect label values causing no pods to match.

The correct API version is policy/v1. The field minAvailable: 3 ensures at least three pods stay up. The selector matches pods labeled component=api.

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