Backend interview: what can a PodDisruptionBudget protect, and what can it not protect?

Prompt and context

You operate a Deployment-managed service with a desired replica count of five. During a cluster upgrade, a node must be drained and the team is worried about losing several replicas at once. The interviewer asks you to design or review a PodDisruptionBudget and explain its effects on rolling releases, node failures, and direct Pod deletion.

This tests Kubernetes availability boundaries and operational reasoning. A PDB limits how many selected replicas may be unavailable simultaneously because of voluntary disruptions. It is not a replica controller and it is not a guarantee against every failure. A good answer connects desired replicas, selectors, the eviction entry point, and remaining capacity.

What the interviewer is evaluating

• Whether you distinguish voluntary from involuntary disruption.
• Whether you explain the mutually exclusive semantics of minAvailable and maxUnavailable.
• Whether you know that a PDB relies on the controller’s desired replica count and a precise Pod selector.
• Whether you can explain drain retries, non-covered deletion paths, and rolling-update boundaries.
• Whether you add replicas, topology, probes, and capacity to the availability plan.

Questions to clarify first

• Is the service managed by a Deployment, StatefulSet, or another supported controller?
• Does the selector match only this workload? A broad selector can mix unrelated Pods into one budget.
• Are you protecting node drains and scale-down, or a power loss? A PDB cannot prevent the latter.
• Are replicas spread across zones with enough capacity and correct readiness? A PDB limits eviction; it does not create capacity.
• How long may maintenance wait? A budget that is too strict can extend the window, while a loose one reduces capacity.

A 30-second answer framework

“A PDB constrains voluntary disruption requests made through the Eviction API. With five replicas, minAvailable: 4 or maxUnavailable: 1 can express that at most one should be lost at a time, but the fields are mutually exclusive. The budget depends on the workload’s desired replicas and an exact selector; node failure, direct Deployment deletion, and application rolling updates are not fully stopped by it. If drain is rejected, I would inspect the budget, healthy replicas, capacity, and eviction path, while using replicas, topology, and probes for the rest of the availability design.”

Deep-dive answer

Classify the disruption

Node drain, node maintenance, and some cluster scale-down actions usually request Pod movement through the Eviction API. They are voluntary disruptions, so the PDB can temporarily reject an eviction. Power loss, kernel failure, or network isolation are involuntary disruptions; a PDB cannot prevent them, and the resulting unavailable Pods still affect the budget state.

Explain the mutually exclusive fields

minAvailable says how many matching Pods must remain available after eviction. maxUnavailable says how many matching Pods may be unavailable after eviction. They cannot both be set. For five desired replicas, minAvailable: 4 and maxUnavailable: 1 express a similar intent at that size, but percentages change with scale and rounding, so state the desired count and version semantics.

Show the dependency on desired replicas and selector

The control plane finds the managing workload through Pod owner references and derives the intended count from .spec.replicas. The selector should match the Deployment or StatefulSet labels and remain narrow. A selector that matches multiple applications creates a shared budget; without a supported owning resource, Kubernetes cannot reliably derive the total.

Use a configuration to show the boundary

This example allows at most one selected Pod to be unavailable from voluntary eviction when the workload intends five replicas:

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

It does not guarantee four healthy Pods at all times. A replica may already be unhealthy, or a node may fail suddenly. Before rollout, verify the selector, readiness, desired replicas, and multi-zone capacity.

Explain drain rejection and retry

When no eviction is currently allowed, healthy replicas are already below minAvailable, or the budget controller cannot compute status, the Eviction API may reject the request. kubectl drain periodically retries failed requests until Pods terminate or a timeout is reached. Troubleshooting starts with PDB status, selected Pods, healthy count, readiness failures, and confirmation that the maintenance action actually uses the Eviction API.

Separate rolling updates and direct deletion

Deployment and StatefulSet rolling updates are governed by their own update strategy; a PDB is not a complete substitute for those rules. A PDB also cannot constrain every direct deletion of a Pod or Deployment. Release systems should combine maxUnavailable, maxSurge, readiness, and rollback behavior instead of delegating all release safety to the PDB.

Add reliability outside the PDB

A PDB covers one disruption class. Resisting node or zone failure also needs enough replicas, topology spread, capacity headroom, correct readiness and liveness, graceful termination, and connection draining. For quorum-based stateful services, derive the budget from quorum needs; for stateless services, validate availability with real traffic, recovery time, and capacity tests.

Model high-quality answer

“The Deployment wants five replicas, so I would first verify that the PDB selector matches only checkout-api and that readiness and cross-zone capacity are sound. If voluntary eviction must leave four available replicas, I can use minAvailable: 4 or maxUnavailable: 1; they are mutually exclusive, and I would choose an absolute value or percentage based on scaling behavior.

The PDB protects node drains, maintenance, and some scale-down actions that use the Eviction API. It cannot stop power loss, kernel failure, or direct Pod deletion, and rolling updates are primarily controlled by the Deployment strategy. If drain is rejected, I would inspect healthy replicas, budget status, selector, readiness failures, capacity, and the eviction path; kubectl drain may retry until timeout.

I would validate the PDB with replicas, topology spread, readiness, graceful termination, and release rollback. A budget that is too strict can block maintenance, while one that is too loose can violate minimum capacity, so the threshold should come from traffic and failure drills rather than a universal percentage.”

Common mistakes

• Claiming a PDB prevents node failure: voluntary and involuntary disruption are confused → limit the claim to the Eviction API path.
• Setting both minAvailable and maxUnavailable: the fields are mutually exclusive → choose one budget expression.
• Counting current Pods only: the budget uses desired replicas → inspect owner references and .spec.replicas.
• Selecting an entire namespace: unrelated apps share one budget → use a narrow workload selector.
• Saying a PDB protects rolling updates and direct deletes: controllers and delete paths have separate semantics → inspect each policy and permission path.
• Deleting the PDB when drain blocks: the capacity risk may grow → inspect healthy replicas, probes, budget status, and capacity first.
• Configuring a PDB without topology or capacity: surviving Pods can share one failure domain → combine zones, headroom, and drills.
• Treating a percentage as a fixed replica count: scaling changes the meaning → state desired scale, rounding, and autoscaling behavior.

Follow-up questions and answers

Follow-up 1: What does minAvailable: 80% mean for five replicas?

It requires the available count produced by the Kubernetes percentage and rounding rules. Do not assume it is always exactly four; verify the current API semantics and observe behavior after scaling.

Follow-up 2: Why can a drain still make the service unavailable?

A PDB limits accepted voluntary evictions; it cannot repair already unhealthy Pods, create capacity, undo single-zone concentration, or make the application tolerate connection movement. Readiness, topology, capacity, and graceful termination must be validated together.

Follow-up 3: Does kubectl delete pod get blocked by a PDB?

Do not assume it does. Kubernetes documents that directly deleting Pods or Deployments can bypass PDB protection, so permissions, audit, and release processes must constrain that path.

Follow-up 4: The PDB shows zero allowed disruptions. Should you loosen it first?

First inspect the selector, desired replicas, healthy replicas, readiness failures, and controller status. Blindly loosening the budget can hide a health problem. If maintenance truly requires a temporary change, evaluate capacity and rollback, record the window, and restore the policy.

Follow-up 5: How do stateful and stateless services differ?

A stateful service must preserve quorum or the consistency protocol’s minimum replicas and validate rebalancing and recovery. A stateless service usually focuses on remaining capacity, latency, and connection draining. Neither availability claim follows from replica count alone.

Follow-up 6: How do you verify the PDB is effective?

In a controlled window, exercise the Eviction API and a node drain, then observe rejection, retries, termination grace, traffic, errors, and recovery time. Also test node failure and direct deletion paths so the team does not mistake the PDB boundary for an all-failure guarantee.