Prompt and context
You own a five-replica stateful service that must retain quorum during node maintenance and cluster scale-down. Design a PDB, choose between minAvailable and maxUnavailable, and explain why outages can still occur after configuring it. Assume a StatefulSet and a maintenance tool that uses the Eviction API.
What the interviewer is testing
- Whether you define the availability and quorum constraint before writing YAML.
- Whether you distinguish voluntary disruption from node failure, resource pressure, and other involuntary disruption.
- Whether you understand that a PDB limits eviction, not the absolute number of healthy Pods at all times.
- Whether you catch rolling-upgrade exceptions, selectors, percentage rounding, and capacity-related drain stalls.
Clarifying questions before answering
- What is the quorum? A five-replica consensus service may require three healthy replicas; a stateless service may target a capacity percentage.
- Who performs the eviction? PDBs are honored by the Eviction API; direct deletion of a Deployment or Pod can bypass them.
- Does maintenance include an application rollout? PDBs do not limit Deployment or StatefulSet rolling updates; the workload strategy does.
- Is there capacity for replacement Pods? An allowed eviction does not mean a replacement can schedule immediately; capacity shortages can block drain.
30-second answer framework
“I first confirm the healthy replica requirement and the eviction path. For five replicas and a quorum of three, I would use minAvailable: 3, or an equivalent maxUnavailable: 2 when replica scale changes, with a selector matching the StatefulSet. A PDB limits voluntary eviction; it cannot prevent node failure or replace a rollout strategy. Before rollout I would run a controlled kubectl drain, inspect disruptionsAllowed, and verify that replacement Pods have schedulable capacity.”
Step-by-step deep answer
1. Translate availability into a budget
A PDB budget is the number of replicas that a voluntary disruption may remove at once. If five replicas must retain three healthy Pods, the budget is at most two. minAvailable: 3 states the remaining healthy count; maxUnavailable: 2 states the allowed unavailable count. The fields are mutually exclusive.
2. Choose the expression that matches scaling
minAvailable is direct for a fixed quorum. If replicas autoscale, Kubernetes documentation recommends considering maxUnavailable, which is evaluated against desired replicas. Percentages round up: with seven desired replicas and maxUnavailable: 30%, three Pods may be unavailable, not two. Capacity planning must include that rounding.
3. Bind the correct workload
The PDB label selector must match the StatefulSet selector. Otherwise it may protect no target Pods or accidentally combine multiple applications. Keep labels stable; do not change them during release to escape the budget.
4. State the PDB boundary
A PDB limits voluntary disruption such as kubectl drain and automated maintenance. Hardware failure, node loss, and resource-pressure eviction are involuntary; the PDB cannot prevent them, and they still count against the budget. Direct deletion of a Pod or Deployment can also bypass it.
5. Explain a stalled drain
When the budget is exhausted, the Eviction API rejects new evictions and the drain retries. Even an allowed eviction can leave its replacement Pending when no node has capacity, so drain remains blocked. Include Pod requests, zone spreading, startup time, and node headroom; a PDB is not a capacity system.
6. Separate rollouts and health policy
A PDB does not limit a Deployment or StatefulSet rolling update; update strategy fields such as maxUnavailable, maxSurge, and readiness control replacement during a release. Kubernetes also provides an unhealthy-Pod eviction policy, which should be chosen based on whether failing Pods must be cleaned up first. Test rollout, maintenance, and incident recovery separately.
High-quality sample answer
I would confirm that the five-replica service needs three healthy replicas for quorum and that the maintenance tool calls the Eviction API. The basic PDB is minAvailable: 3 with the StatefulSet’s exact selector. If replicas autoscale, I would evaluate maxUnavailable: 2 or a percentage with its rounding behavior. The PDB limits voluntary eviction only; it does not prevent node failure, resource pressure, direct deletion, or a rolling-update policy.
During rollout I would inspect disruptionsAllowed, run a controlled drain, and observe termination time, replacement scheduling, and quorum state. A paused drain when the budget is exhausted is expected. If replacements are Pending, I would add capacity or adjust requests rather than widening the budget. Finally I would test upgrade, node-loss, and maintenance rollback paths separately.
Common mistakes
- Mistake → Assuming a PDB prevents every outage. Why it fails: involuntary disruptions are outside its control. Fix: state the boundary for node failure, pressure, and maintenance eviction.
- Mistake → Writing only
maxUnavailable: 50%. Why it fails: round-up behavior can allow more replica loss than intuition suggests. Fix: calculate it from desired replicas. - Mistake → Treating a PDB as a rollout policy. Why it fails: Deployment and StatefulSet updates are not limited by the PDB. Fix: configure workload update strategy separately.
- Mistake → Blaming the PDB for a stuck drain. Why it fails: exhausted budget and missing node capacity have different causes. Fix: inspect
disruptionsAllowed, Pending Pods, requests, and capacity together.
Follow-up questions and responses
Only three of five replicas are healthy. Can another Pod be evicted?
With minAvailable: 3, voluntary eviction should be rejected by the Eviction API. Restore a healthy replica or accept a maintenance pause; deleting the PDB to make drain finish would remove quorum protection.
The cluster autoscaler is stuck. Should you loosen the PDB?
First verify that scale-down is voluntary, the budget is exhausted, and replacement Pods can schedule. Loosening a quorum service’s budget may break consistency. Add capacity, change the drain batch, or use a capacity percentage for a stateless workload instead of weakening every application’s budget.
Why can direct Pod deletion bypass the PDB?
The PDB governs voluntary eviction requests through the Eviction API, not every delete operation. Restrict direct-delete permissions and make maintenance automation use the API, while keeping an explicit administrator bypass for emergencies.
What is the risk of maxUnavailable: 0?
It requires zero voluntary unavailable Pods, so a node drain can never complete while the selected workload remains there. Use it only when the business cannot tolerate voluntary disruption and a coordinated maintenance procedure exists.