Kubernetes PodDisruptionBudget Interview Questions: Drains, Rollouts, and Availability

Your interviewer says a three-replica API has a PodDisruptionBudget (PDB) with minAvailable: 2. A node drain is stuck, yet a Deployment update seems able to replace Pods. Is the budget broken? The answer depends on who initiates the disruption, how many selected Pods are healthy, and whether the operation uses the Eviction API. A convincing interview answer follows those mechanics through an actual maintenance window instead of repeating that a PDB “keeps two Pods running.”

This guide uses Kubernetes documentation for platform behavior. The cluster sizes, events, and sample answers are original interview exercises, not reports of questions asked by a named employer. For related practice, try Diagnose overloaded Kubernetes cluster after working through the drain scenario yourself.

The one distinction every PDB answer needs

A PDB sets a floor on availability for voluntary disruptions that use the Kubernetes Eviction API, such as a normal kubectl drain. The API checks the budget before accepting each eviction. A controller then creates a replacement Pod, but that replacement still needs a schedulable node, startup time, and readiness before it counts as healthy. The budget cannot manufacture spare capacity or make a slow application ready.

An involuntary failure—hardware loss, a kernel crash, or a sudden node outage—can violate the budget. The PDB does not prevent it. A Deployment rolling update also does not use the PDB as its rollout throttle; its own maxSurge and maxUnavailable settings govern the update. However, Pods made unavailable by the rollout affect the PDB's observed healthy count and can block a concurrent drain. That asymmetric interaction is often the crux of the interview question. These distinctions follow the Kubernetes disruption guide and Deployment behavior.

Say the PDB selector matches the three API Pods, all are Ready, and minAvailable: 2. Kubernetes may allow one healthy Pod eviction. If a replacement is Pending or unready, the second eviction must wait. If a rollout has already left one selected Pod unavailable, the same drain may have zero disruptions available before it starts. A superficially correct budget can therefore halt maintenance for a very real availability reason.

Interview question 1: A drain hangs with three replicas and minAvailable two. What do you inspect?

Start with scope. Confirm that the PDB selector matches the intended Pods and that its expected count corresponds to the owning workload. Check kubectl get pdb -n <namespace> and kubectl describe pdb <name> -n <namespace> for currentHealthy, desiredHealthy, expectedPods, and disruptionsAllowed. Then inspect Pods selected by the budget, their readiness conditions and placement, and the event stream from the drain. Do not infer the cause merely from replica count: three desired replicas are not three healthy replicas.

Next ask whether one Pod is already unavailable because of a rollout, probe failure, or previous eviction. If currentHealthy equals desiredHealthy, there is no headroom for another voluntary eviction. If a replacement Pod is Pending, inspect kubectl describe pod events for capacity, affinity, taints, topology, and PVC constraints. If it is Running but unready, inspect the readiness probe and application startup. The operational decision follows the observation: repair readiness, add eligible capacity, or schedule maintenance after the rollout. Deleting Pods directly to “unstick” the drain bypasses the protection the PDB was meant to provide.

An interviewer may press on a failing Pod. Current Kubernetes documentation recommends unhealthyPodEvictionPolicy: AlwaysAllow for PDBs when you want drains to evict misbehaving Pods instead of waiting indefinitely for them to become healthy. That policy changes treatment of unhealthy Pods during eviction; it does not make healthy-replica shortages safe. State the policy explicitly rather than assuming all clusters use it.

A three-Pod drain, worked from the status fields

Consider api with three desired replicas across nodes A, B, and C. One PDB selects these Pods with minAvailable: 2. All three are healthy at 09:00. Operations drains A, and the eviction is accepted. The Deployment creates a replacement, but the scheduler cannot place it because B and C have insufficient allocatable CPU. At 09:02, the team tries to drain B.

Time and observation	PDB implication	Defensible next move
09:00: three selected Pods Ready	currentHealthy: 3, desiredHealthy: 2; one voluntary disruption can be accepted	Drain one node and watch the replacement
09:01: Pod on A terminating; replacement Pending	Only two selected Pods remain healthy; no new healthy eviction headroom	Inspect Pending-Pod scheduling events and node capacity
09:02: B drain requests another eviction	Eviction should be denied or retried while the floor would be crossed	Stop the second drain; provide eligible capacity or restore a Ready replica
09:08: replacement becomes Ready on an eligible node	Healthy count returns to three; a new eviction may be allowed	Resume maintenance one node at a time, rechecking status

This table is an illustrative inference from the documented Eviction API and PDB status model, not an observed production timeline. In practice, terminating Pods, readiness transitions, and controller reconciliation make status transient; re-read the object and events at the decision point. If the workload cannot fit a fourth Pod anywhere, extra replica settings alone will not rescue the drain.

Interview question 2: Why can a rollout proceed while a drain cannot?

Because a PDB and a Deployment govern different operations. A Deployment rolling update replaces Pods under its rollout strategy. For example, replicas: 3, maxSurge: 1, and maxUnavailable: 0 allow the controller to create one additional Pod before making an old one unavailable, provided the new Pod can be scheduled and become Ready. The PDB is not a second gate on that controller's ordinary rolling update. A concurrent drain still calls the Eviction API and must pass the PDB check.

The trap is to say “the PDB has no effect on rollouts,” then stop. A rollout that temporarily reduces Ready Pods changes what the PDB sees. If a new Pod is unready and an old Pod has been removed, the PDB may report zero allowed disruptions. Conversely, maxUnavailable: 0 does not guarantee uninterrupted user traffic if readiness is wrong or an old Pod terminates active connections abruptly. The answer should name the separate controls and then describe their coupled availability outcome.

If asked whether kubectl rollout undo restores the situation, keep the scope precise. It can return the Deployment's Pod template to a previous revision, but it is not a time machine for database migrations, external writes, or an already-drained node. The more relevant incident decision may be to pause the rollout, restore capacity, and then resume drains under a measured budget.

Interview question 3: minAvailable or maxUnavailable—which should you choose?

Both express a budget, but they communicate different operational contracts. minAvailable: 2 states an absolute healthy floor. For a fixed three-replica service whose load test says two healthy replicas can safely serve traffic, that is easy to review. maxUnavailable: 1 states the maximum unavailable portion and may scale more naturally when replica count changes. Percentage values require careful interpretation and rounding; a small replica count can produce surprising behavior. Review the chosen expression against the actual minimum serving capacity and the intended maintenance concurrency, not simply against replica count.

Only one of minAvailable and maxUnavailable can be set on a single PDB. A PDB can make draining impossible if its requirement cannot be met, such as minAvailable equal to all healthy replicas without spare replacement capacity. That may be intentional for a stateful quorum during a risky period, but it needs an explicit operational plan. For stateful services, explain what “available” means beyond Kubernetes Ready: quorum, leader placement, and data resynchronization can impose a stricter application-level floor than the PDB alone understands.

In an interview, state the service's tested minimum first. Then choose a policy and calculate one drain step. If you cannot defend why two healthy Pods are enough under the expected peak traffic and failure domain, neither YAML value is a safety argument.

Interview question 4: What if the Pod is unhealthy before maintenance?

This is where vague advice to “wait for the PDB” fails. A Pod can be Running but not Ready, or Ready according to a weak probe while unable to serve meaningful work. First establish its actual condition and whether it is selected by the budget. Kubernetes counts healthy selected Pods for PDB decisions, using readiness as the platform signal. The application may require additional checks, especially for queues or stateful roles.

With the default unhealthy-Pod behavior, a drain can wait on a Pod that cannot recover. The PDB configuration task discusses unhealthyPodEvictionPolicy and recommends AlwaysAllow for common maintenance workflows. Use that documented policy with a clear operational rationale: it permits eviction of unhealthy Pods so a broken member does not indefinitely block a node drain. It does not let the operator evict healthy Pods below the desired healthy floor.

If currentHealthy is already below desiredHealthy, investigate the workload incident before expanding the maintenance blast radius. A PDB is a guardrail, not a cure for a bad readiness probe, failed rollout, unavailable node pool, or unschedulable replacement.

Interview question 5: How would you coordinate a rollout and node maintenance?

Give the interviewer a sequence with observable gates. Identify the PDB selector, workload owner, replica count, and failure-domain placement. Check the current PDB status and Deployment rollout status; confirm there are no unready selected Pods. Verify that the remaining nodes have resources and satisfy scheduling constraints for replacements. Then run one drain, wait for replacement readiness and a recovered disruptionsAllowed value, and only then proceed to the next node. If a rollout is active, either finish it or deliberately pause it before draining, depending on service urgency and capacity. Coordinate with the application owner when two Ready replicas are not sufficient for peak load.

For the rollout itself, choose maxSurge and maxUnavailable from actual headroom and readiness behavior. Watch kubectl rollout status deployment/<name> and Pods, not just the command exit code. A healthy rollout can consume the very spare capacity a drain needs, while a drain can constrain where surge Pods land. If a rollout stalls, collect Events and probe results before a rollback. Record which operation owns each unavailable Pod so the team does not misdiagnose a PDB rejection as a scheduler bug.

This is an interview answer framework, not an official Kubernetes maintenance prescription. The exact order can change for urgent security work, stateful quorum, and cluster autoscaler behavior. The invariant is evidence-based gating: one operation should not assume the other's availability budget is independent.

What a strong answer sounds like

“I would first check whether this is a voluntary Eviction API operation. For minAvailable: 2 and three healthy selected Pods, one eviction has room; the second needs a Ready replacement. I would read the PDB status, Pod readiness, scheduling events, and Deployment rollout status. A rolling update follows its own surge and unavailable limits, although an unready rollout Pod can reduce the PDB's disruption allowance for a concurrent drain. I would restore capacity or readiness before forcing more maintenance.”

That answer has a concrete mechanism, a falsifiable observation, and a safe next step. Avoid claiming the PDB protects against node failure, guarantees user-facing availability, or directly controls Deployment rollout speed. If you need more practice, use the linked prompts below and explain which operation owns the disruption before discussing commands.

Practice question	What to rehearse
Diagnose overloaded Kubernetes cluster	Show when a replacement is Pending because the remaining nodes lack capacity.
Design and operate a monolith on Kubernetes	Connect replica strategy, readiness, and node maintenance.
Explain How Microservices Run and Fail on Kubernetes	Separate Pod availability signals from service-level availability.
Explain CI/CD, Kubernetes delivery, and troubleshooting	Distinguish rollout controls from drain eviction controls.
Describe how you use Kubernetes	Give an operational example with status fields and a decision.

The best next exercise is to sketch your own three-node cluster and predict disruptionsAllowed after each eviction and readiness transition. Then practice Diagnose overloaded Kubernetes cluster while stating which observation would change your decision.

Sources and further reading

• Kubernetes: Disruptions — voluntary versus involuntary disruptions, Eviction API, and rollout interaction.
• Kubernetes: Configure a PodDisruptionBudget — budget configuration and unhealthy Pod eviction policy.
• Kubernetes: Deployments — rolling update and rollout status controls.
• Kubernetes: Safely Drain a Node — operational drain behavior.