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.