Pod Disruption Budgets in Kubernetes - Time & Space Complexity

Time Complexity: Pod Disruption Budgets

O(n)

Understanding Time Complexity

We want to understand how the time to process Pod Disruption Budgets changes as the number of pods grows.

Specifically, how does Kubernetes handle checking and enforcing these budgets when many pods exist?

Scenario Under Consideration

Analyze the time complexity of the following Pod Disruption Budget (PDB) enforcement snippet.

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

This PDB ensures at least 2 pods with label app=myapp stay running during disruptions.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Kubernetes lists and counts all pods matching the PDB selector.
• How many times: It checks each pod once per disruption event to verify availability.

How Execution Grows With Input

As the number of pods matching the selector increases, the time to check them grows linearly.

Input Size (n)	Approx. Operations
10	10 pod checks
100	100 pod checks
1000	1000 pod checks

Pattern observation: The checking time grows directly with the number of pods.

Final Time Complexity

Time Complexity: O(n)

This means the time to enforce the PDB grows in direct proportion to the number of pods it monitors.

Common Mistake

[X] Wrong: "Checking a PDB always takes constant time regardless of pod count."

[OK] Correct: Kubernetes must examine each pod to count availability, so more pods mean more work.

Interview Connect

Understanding how Kubernetes scales checks like PDB enforcement helps you reason about system behavior under load.

Self-Check

What if the PDB selector matched multiple labels instead of one? How would the time complexity change?