Last reviewed: November 7, 2026 (Asia/Shanghai); official Kubernetes references checked November 7 UTC.

Direct answer

Review a Kubernetes PodDisruptionBudget (PDB) in a coding-agent patch by starting with the workload’s availability contract, then checking the rendered selector and budget against the Pods it is meant to protect. Verify whether the change governs voluntary evictions, whether it accidentally selects zero or too many Pods, and whether the chosen minAvailable or maxUnavailable still permits the maintenance action the cluster needs. Finally, exercise the Eviction API in an authorized disposable cluster and retain PDB status, Pod identity, and recovery evidence.

A PDB is a limit on voluntary disruption for a selected collection of Pods. It does not prevent involuntary failures such as a node crash, and it does not automatically constrain every deletion or rollout path. The Kubernetes disruptions reference explains those boundaries. The PDB configuration task describes selector, availability, percentage rounding, status inspection, and unhealthy-pod eviction choices. The policy/v1 API reference defines the fields and status values a reviewer should inspect.

Who this is for

Use this workflow when a coding agent edits a PDB manifest, a Helm value, a Kustomize overlay, a workload label, or a controller that creates PDBs for a Deployment or StatefulSet. It is intended for maintainers protecting application capacity during node drains, cluster upgrades, or other API-mediated voluntary evictions. It also applies when an agent changes replica counts or selector labels near an existing PDB.

Give the agent the application’s minimum serving capacity, replica and rollout policy, namespace, and cluster version before requesting a change. Ask for a rendered manifest, a plain-language explanation of the selected Pods, and an acceptance plan. The examples below are review procedures and synthetic fixtures; no production eviction or authenticated cluster test was run for this article.

Key takeaways

  • Define the availability floor before choosing minAvailable or maxUnavailable.
  • Resolve the PDB selector against the admitted Pod labels and the owning workload, not just the source YAML.
  • Percentages are rounded according to the field’s semantics; calculate the result at every supported replica count.
  • A PDB limits voluntary Eviction API actions. It does not repair crashed Pods or block every delete, rollout, or node failure.
  • Inspect currentHealthy, desiredHealthy, expectedPods, disruptionsAllowed, and observedGeneration together.
  • Test a permitted eviction and a refusal with fresh Pod identities, then prove that replacement Pods become healthy.
  • Treat an unhealthy-pod eviction policy as an explicit availability and maintenance decision.

Sources checked

Three primary Kubernetes references were retrieved successfully on November 7, 2026 UTC:

  • Disruptions distinguishes voluntary and involuntary disruptions, explains what a PDB protects, describes the Eviction API and kubectl drain, and notes actions that bypass PDBs.
  • Protecting an Application with a PodDisruptionBudget documents application-specific budget choices, percentage rounding, selectors, status checks, and unhealthyPodEvictionPolicy.
  • PodDisruptionBudget policy/v1 API reference defines minAvailable, maxUnavailable, selector matching, unhealthy-pod policy values, and status fields such as disruptionsAllowed and observedGeneration.

These maintained references support an evergreen review task. The concept page reports a May 16, 2025 modification, the configuration task reports an October 6, 2026 modification, and the generated API reference reports an August 26, 2026 modification. Match the documented behavior to the target Kubernetes version and distribution before approving a patch.

Contract details to verify

State the availability contract first

Write the disruption contract in terms of serving capacity and recovery, not a copied percentage. For a stateless frontend with ten replicas, the owner might allow one voluntary eviction while nine replicas remain available. A quorum-based workload may need a minimum number of healthy members. A single-instance service may require a human decision rather than a PDB that permanently blocks maintenance. A batch Job may not need a PDB because its controller creates a replacement.

Record the workload kind, namespace, owner reference, supported replica range, quorum or serving floor, rollout strategy, and the voluntary actions the cluster owner expects to perform. Include the recovery assumption: a budget can preserve capacity during an eviction, but it cannot make a replacement Pod start, schedule, or become ready.

The disruptions reference separates voluntary events, such as a node drain or planned maintenance, from involuntary events, such as hardware failure or resource pressure. Do not present a PDB as a general uptime guarantee. If the patch claims to protect a node failure, ask for the separate replication, topology, and capacity evidence that supports that claim.

Resolve selector coverage from the rendered Pod

Render every affected Helm chart or overlay and inspect the final Pod template labels. A PDB selector is namespace-scoped. It must match the Pods the owner intended, and it must not silently include another workload sharing a label. Check the namespace, selector operators, label values, and any labels added by the agent or an admission webhook.

The API reference says a null selector matches no Pods, while an empty selector {} selects every Pod in the namespace. Treat either as a high-risk change unless the owner explicitly chose it. A selector matching zero Pods can make the PDB look healthy while protecting nothing. A broad selector can make an unrelated workload unevictable and cause a drain to stall.

Compare the PDB selector with the owning controller’s selector and the actual labels on admitted Pods. For a Deployment, inspect the ReplicaSet and Pod labels after rendering; for a StatefulSet, inspect every ordinal represented in the test fixture. If the agent changed a workload label, review the PDB and workload in one candidate. Record the exact matching Pod names and UIDs in the review evidence.

When more than one PDB selects a Pod, inspect all of them. The API reference notes that the eviction decision is affected by every matching budget. A patch that introduces an overlapping PDB can therefore make an otherwise valid eviction fail, while a selector typo can leave the intended workload outside the protection boundary.

Calculate availability and percentage rounding

Use exactly one of minAvailable or maxUnavailable in a PDB. minAvailable states how many selected Pods must remain available after an eviction; maxUnavailable states how many may be unavailable after it. Each accepts an integer or percentage string. Keep the chosen form aligned with the owner’s scaling model and calculate it for the smallest, normal, and largest supported replica counts.

For example, a five-replica service with minAvailable: "60%" needs at least three available Pods. A six-replica service with the same percentage needs at least four. The configuration task describes percentage rounding; do not assume that a percentage maps to the same integer at every scale. Likewise, a maxUnavailable percentage rounds up according to Kubernetes semantics. Capture the computed floor or ceiling in the review record instead of leaving it implicit.

For healthy selected Pods, minAvailable: 100% or maxUnavailable: 0 leaves no voluntary healthy-Pod eviction available while the selected set is at the required health level. That does not mean every Eviction request is rejected: a running but not-ready Pod can still be evicted according to unhealthyPodEvictionPolicy—AlwaysAllow regardless of the budget, and IfHealthyBudget when currentHealthy is at least desiredHealthy. Treat the health state and policy value as part of the contract. A zero budget may be correct for a short protected operation, but it can also make kubectl drain wait indefinitely. A budget that permits one disruption at ten replicas may permit none at a lower scale if the percentage rounds to the availability floor. Test the smallest supported replica count, including the rollout’s surge and unavailable settings.

This example illustrates a reviewable contract for a Deployment with the label app: api:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: review-workloads
spec:
  selector:
    matchLabels:
      app: api
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow

The values are illustrative. Derive them from the application’s serving floor and the cluster owner’s maintenance plan. AlwaysAllow is a deliberate choice discussed below; do not add it merely to make a drain pass.

Separate PDB status from Pod readiness

Before an eviction test, read the budget status and the selected Pods. The API reference defines currentHealthy, desiredHealthy, expectedPods, disruptionsAllowed, and observedGeneration. Status can trail the actual system, so bind the observation to the PDB generation. If observedGeneration does not equal the current metadata generation, wait for reconciliation or record the status as stale.

A useful read-only evidence capture in an authorized test namespace is:

kubectl --context review-cluster --namespace review-workloads \
  get poddisruptionbudget api-pdb -o json |
  jq '{generation: .metadata.generation,
       status: {currentHealthy: .status.currentHealthy,
                desiredHealthy: .status.desiredHealthy,
                expectedPods: .status.expectedPods,
                disruptionsAllowed: .status.disruptionsAllowed,
                observedGeneration: .status.observedGeneration},
       selector: .spec.selector,
       minAvailable: .spec.minAvailable,
       maxUnavailable: .spec.maxUnavailable,
       unhealthyPodEvictionPolicy: .spec.unhealthyPodEvictionPolicy}'

kubectl --context review-cluster --namespace review-workloads \
  get pods -l app=api -o json |
  jq '[.items[] | {name: .metadata.name, uid: .metadata.uid,
       phase: .status.phase,
       ready: ([.status.conditions[]? | select(.type == "Ready") | .status] | first),
       deletionTimestamp: .metadata.deletionTimestamp}]'

Do not equate disruptionsAllowed with a permanent reservation. It is the number of disruptions currently allowed by the controller’s observed state, and it changes as Pods become ready, unready, or are marked for disruption. A zero value can be the correct result when the application is at its floor; it can also indicate a selector mismatch, a failed replacement, or stale status. Investigate the cause before changing the budget.

Choose the unhealthy-pod policy intentionally

The stable unhealthyPodEvictionPolicy field controls when running but not-ready Pods can be evicted. The configuration task and API reference describe IfHealthyBudget and AlwaysAllow. With IfHealthyBudget, an unhealthy running Pod is constrained unless the guarded application is otherwise at or above its desired healthy count (currentHealthy >= desiredHealthy). With AlwaysAllow, running unhealthy Pods can be evicted regardless of whether the budget is currently met.

AlwaysAllow can let a node drain remove a misbehaving Pod that is blocking maintenance, but it can also reduce serving capacity while a replacement is not ready. IfHealthyBudget can protect the remaining healthy floor, but a broken Pod may keep a node drain from completing. Require the workload owner and cluster operator to state which trade-off they want. Test the selected behavior with one Pod that is running but fails readiness, while a second healthy Pod provides a positive control.

Pending, Succeeded, and Failed Pods have their own treatment in the documented policy. Do not infer behavior from the word “unhealthy” alone; record phase, Ready condition, and the exact policy value.

Exercise eviction and recovery in a disposable cluster

Use a synthetic workload with enough replicas to make the budget meaningful. Establish a healthy baseline and capture the PDB generation, status, selected Pod UIDs, readiness, and replica controller state. Confirm that the cluster’s eviction path and node-drain tooling respect PDBs; the concept page advises application owners to confirm this with the cluster owner or provider.

Request one eviction through the Eviction API or the approved drain workflow. If disruptionsAllowed is positive and the selected Pod is healthy, the request should be accepted under the rendered budget. Record the eviction response, deletion timestamp, replacement Pod UID, and time to Ready. Do not call acceptance a success until the replacement is scheduled and the service returns to the stated floor.

Then create a controlled refusal case. Reduce the available replicas to the budget floor, or issue a second eviction before the replacement becomes healthy, while keeping a healthy positive-control Pod. The expected result is an eviction refusal attributable to the PDB, with the budget status and exact selected Pods attached. A generic timeout is not enough: authorization, a missing Eviction subresource, a node issue, or a failed API request can look similar.

Restore the baseline between cases. Use fresh requests and Pod UIDs; reusing a connection or an old Pod name can hide replacement behavior. Capture events, controller conditions, scheduling messages, readiness transitions, and PDB status before and after each operation. No test should delete the PDB or alter production policy to make the eviction green.

Distinguish PDB behavior from rollout and deletion behavior

A PDB is consulted by the Eviction API. The disruptions reference warns that deleting a Deployment or Pod can bypass a PDB, and involuntary disruptions are not prevented by it. Workload rolling updates have their own availability settings. Review maxUnavailable, maxSurge, replica count, and controller behavior alongside the PDB instead of assuming one object defines the entire rollout contract.

If an agent changes a Deployment selector, rollout strategy, or termination grace period at the same time, split the acceptance evidence by boundary. A successful PDB eviction does not prove that a rollout preserves capacity; a healthy rollout does not prove that a node drain honors the budget. For a companion review of readiness and restart consequences, use Review Kubernetes Health Probes in Coding-Agent Patches . For resource and scheduling interactions, use Review Kubernetes Requests and Limits in Coding-Agent Patches .

Failure modes

The budget selects no Pods. Inspect the admitted labels, namespace, and selector operators. Require matching Pod names and UIDs before treating status as meaningful.

An empty selector is accepted as harmless. In policy/v1, {} selects every Pod in the namespace. Review it as a namespace-wide availability policy.

A percentage is reviewed at only one scale. Calculate the rounded result at minimum, normal, and maximum replicas, including rollout surge behavior.

A PDB is expected to stop node loss. Involuntary disruptions are outside its protection. Require replication, topology, and capacity evidence for that failure mode.

A drain hangs and the agent sets maxUnavailable to zero. Diagnose selector coverage, unhealthy Pods, and the maintenance requirement first. A permanently unevictable workload can transfer operational risk to the node owner.

The test reports a replacement Pod as the original recovery. Bind observations to Pod UID and controller revision. A new Pod and a restarted container are different events.

Only a successful eviction is tested. Add a floor/refusal case and retain a healthy positive control so an outage cannot masquerade as PDB enforcement.

FAQ

Does a PDB guarantee that an application stays available?

No. It limits selected voluntary evictions when the eviction path honors the budget. It cannot prevent node failure, resource pressure, application bugs, or every deletion and rollout path.

Should every Deployment have a PDB?

No. Use one when the application has a defined voluntary-disruption contract and the cluster performs actions that should respect it. Choose the budget from serving or quorum needs; a blanket PDB can block useful maintenance.

Is maxUnavailable: 1 equivalent to minAvailable: 1?

Not generally. They express different constraints and interact differently with replica count and percentage rounding. Compute the resulting floor for the supported scales and verify it against the API semantics.

Why can disruptionsAllowed be zero when Pods look Ready?

The status may be stale, the desired healthy count may equal the current count, another matching PDB may constrain the eviction, or a disruption may already be in progress. Inspect observedGeneration, all matching budgets, and the controller’s selected Pods.

Should I always set unhealthyPodEvictionPolicy: AlwaysAllow?

No. It can unblock maintenance around misbehaving Pods, while IfHealthyBudget can preserve the healthy floor. Choose and test the policy with the application owner and cluster operator.

Reader next step

Choose one coding-agent PDB change. Render the workload and budget together, list every matching Pod and overlapping budget, calculate the availability result at supported replica counts, and capture a generation-matched status snapshot. Run one permitted Eviction API request and one floor/refusal case in the approved disposable environment. Attach the eviction response, Pod UIDs, replacement readiness, events, and recovery observations to the pull request before approving the patch.