---
title: "A Pod Disruption Budget Is an Eviction Constraint, Not an Uptime Guarantee"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/gpu-kubernetes-disruption-budget-voluntary-eviction"
last-updated: "2026-10-20"
---

# A Pod Disruption Budget Is an Eviction Constraint, Not an Uptime Guarantee

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

A Kubernetes Pod Disruption Budget can hold up a covered Eviction API request when the current allowance is insufficient. That constraint can help coordinate maintenance, but it creates neither a replacement replica nor a spare GPU. A buyer evaluating a maintenance promise must establish which removals respect the budget, what the selected Pods' Ready count means, and what separately supports application continuity.

## What the platform checks when an eviction is requested

A Pod Disruption Budget, or PDB, identifies a Pod population through a label selector. Its availability requirement constrains covered evictions within that population. A budget attached to one inference workload does not automatically cover every GPU workload in the cluster.

For an Eviction API request, the API server performs admission checks against the applicable budget. Sufficient allowance permits the eviction to proceed toward Pod termination. An insufficient allowance can cause the request to be rejected for now. Permission to terminate the Pod does not establish that a replacement is already serving.

The policy/v1 status distinguishes currentHealthy, the healthy Pod count; desiredHealthy, the minimum desired healthy count; and disruptionsAllowed, the number of disruptions currently allowed. Reading those fields requires attention to status freshness and evictions already being processed, as the example below shows.

This interpretation uses official Kubernetes policy/v1 references checked October 20, 2026. The platform provider should identify the offered release, selected population and maintenance mechanism. The discussion explains the constraint for a buyer; it supplies no maintenance procedure.

References: [PD3](https://kubernetes.io/docs/reference/kubernetes-api/policy/pod-disruption-budget-v1/), [EV1](https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/)

## Separate covered eviction from other ways a Pod disappears

A voluntary change is not automatically constrained by a PDB. Maintenance using the Eviction API can encounter its refusal; direct deletion of a Pod or Deployment bypasses it.

Involuntary failures cannot be prevented by the budget, although their unavailability counts against it.

Application rolling updates have a separate boundary: their unavailable Pods count against the budget, but Deployment and StatefulSet rolling updates are not limited by the PDB.

A claim that all planned changes respect the budget therefore needs to name the included removal mechanisms. A host failure can reduce headroom; an application update can proceed under its own controls. The word voluntary settles neither case.

References: [PD1](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/)

## The same seven-and-five counts can support different conclusions

Consider an invented inference workload with seven selected Pods, all Ready, and one applicable PDB with an absolute minAvailable of five. Compare two provider observations before interpreting a claim that two Pods can be removed.

Observation A is stipulated current and settled: status.observedGeneration matches metadata.generation, the controller has caught up with the selected Pods, and no evictions or other removals are in flight. Assume no overlapping budgets and all other relevant admission and controller conditions satisfied. These inputs isolate the count calculation.

Under A's assumptions, the margin is seven minus five, or two Pods. Two healthy-Pod removals fit the count arithmetic before a replacement contributes. Each actual request still depends on the then-current state; this observation reserves no future permission.

Observation B retains the same remembered currentHealthy of seven and desiredHealthy of five, but status.observedGeneration does not match metadata.generation. The API reference makes that match a condition for valid status. B therefore cannot establish a current margin of two. It supplies neither an updated allowance nor an actual admission result. Generation matching alone would also leave A's separate assumption of caught-up state unproven.

Pending evictions are another reason to reject unconditional Ready-minus-minimum reasoning. The disruptedPods map records evictions processed by the API server but not yet observed as marked for deletion by the PDB controller. A healthy-count display alone leaves that accounting unanswered.

Return to A and stipulate one involuntary loss: one selected Pod no longer contributes to the Ready count, and no replacement has become Ready. After status has caught up, six remain Ready. With no removals in flight and the other conditions unchanged, the margin is six minus five, or one. The failure was not prevented; it reduced the headroom for covered eviction.

If a subsequent covered removal leaves five Ready, the margin becomes zero once that change is reflected. Another covered eviction of a healthy selected Pod would leave four, below the stipulated minimum. The budget can constrain that next request even though it could not prevent the earlier failure.

The quantities here are Pods, with no GPUs-per-Pod relationship supplied. The example is count reasoning, with no recommended replica count or observed deployment result.

References: [PD2](https://kubernetes.io/docs/tasks/run-application/configure-pdb/), [PD3](https://kubernetes.io/docs/reference/kubernetes-api/policy/pod-disruption-budget-v1/)

## Ready is the health status used by this mechanism

Kubernetes' PDB guidance counts a Pod as healthy when its Ready condition has status True. The Pod lifecycle documentation distinguishes Ready from the Running phase and describes Ready as eligibility to serve requests through matching Services.

In the fictional case, five Ready Pods meet the stipulated minimum count. What the application's readiness indication actually checks determines the meaning of that health observation. The existing probe guide explains the separate startup, readiness and liveness actions.

References: [PD2](https://kubernetes.io/docs/tasks/run-application/configure-pdb/), [P1](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)

## A removal constraint can preserve the count while maintenance waits

Continue the fictional case at five Ready Pods. Stipulate that the workload controller has created replacement Pods, but none can be placed because no eligible GPU resources are available. No replacement becomes Ready. The next covered healthy-Pod eviction remains constrained by the minimum.

Kubernetes documents this general dependency: a replacement that cannot be scheduled for lack of resources can leave a node drain waiting. Even an included node provisioner has separate limits; its configuration and provider capacity can prevent it from making Pods schedulable. The related replica-versus-node guide explains the separate worker-capacity decision.

A waiting request may therefore be consistent with the removal policy while the maintenance window remains unresolved. The budget does not supply the resources or application readiness needed to restore the margin.

References: [PD1](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/), [N1](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/)

## Make the maintenance promise describe the outcome it supports

Read a statement such as minimum five available during maintenance against the worked case. First establish whether the named removal path respects the applicable PDB. Then distinguish A's stipulated current state from B's invalid stale status: identical counts do not support the same present-tense claim.

Next connect the replacement-capacity evidence to the promised maintenance window. A current allowance can support a covered request without showing that its replacement can be placed and become Ready. At five Ready, the budget can constrain another covered removal while the capacity shortage remains unresolved.

Finally, define available for the application purchase. A Ready-Pod count is no measurement of acceptable model output, latency or completed requests under the intended demand. A promise of continuity needs application evidence across the maintenance interval, tied to the offered model, software, load and required response conditions. An observation collected only after replacements are Ready leaves the intervening user experience unanswered; the related performance guide develops that evidence question.

Assign the removal path, current status and replacement dependencies to the platform provider, and the useful-request result to the application provider. These four questions—coverage, Ready health, replacement capacity and application continuity—explain different ways the wider promise can remain unsupported. Kubernetes explicitly cautions that a disruption budget cannot guarantee its specified population is always up: a failure can take it below the minimum.

References: [PD1](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/), [PD2](https://kubernetes.io/docs/tasks/run-application/configure-pdb/), [PD3](https://kubernetes.io/docs/reference/kubernetes-api/policy/pod-disruption-budget-v1/), [N1](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/)

## Connect a separately selected equipment addition to physical installation

If the capacity decision separately leads to equipment that needs installation, Leviathan's Complete Physical Infrastructure Deployment service can scope agreed receiving, rack integration, onsite installation, IT cabling and physical handoff records.

Use the related service and project inquiry with a nonconfidential equipment summary, quantities, site, connection requirements and receiving platform team. Scope and availability are confirmed for the engagement. Kubernetes policy administration and application acceptance remain with the appointed platform and software teams.

References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment)

## Primary sources

- [PD1 — Kubernetes - Disruptions](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/). Checked 2026-10-20. Coverage of involuntary disruption, direct deletion and application rolling updates; the documented resource-shortage example explains why maintenance can wait.
- [PD2 — Kubernetes - Specifying a Disruption Budget for your Application](https://kubernetes.io/docs/tasks/run-application/configure-pdb/). Checked 2026-10-20. Absolute minAvailable, Ready=True health counting and the explicit limit on availability guarantees.
- [PD3 — Kubernetes API - PodDisruptionBudget, policy/v1](https://kubernetes.io/docs/reference/kubernetes-api/policy/pod-disruption-budget-v1/). Checked 2026-10-20. Official policy/v1 field definitions and status validity: observedGeneration must match the PDB object generation; status can lag actual state and disruptedPods tracks processed evictions awaiting controller observation.
- [EV1 — Kubernetes - API-initiated Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/). Checked 2026-10-20. Explains the request's admission boundary and subsequent Pod termination; an admitted eviction is distinct from application continuation.
- [P1 — Kubernetes - Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/). Checked 2026-10-20. Running phase and Ready condition definitions, including matching-Service eligibility; application performance requires evidence for the offered workload.
- [N1 — Kubernetes - Node Autoscaling](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/). Checked 2026-10-20. Provisioning constraints and provider-capacity limits; no GPU worker availability or provisioning duration is assumed.
- [L1 — Leviathan Systems - Complete Physical Infrastructure Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Agreed physical delivery stages and engagement-defined resources, scope and availability for a separately selected equipment project.

## Related Leviathan resources

- [Inference replicas and GPU nodes: separate the capacity decisions](/articles/gpu-inference-replica-versus-node-autoscaling)
- [Startup, readiness and liveness probes make different decisions](/articles/inference-startup-readiness-liveness-probe-actions)
- [Compare useful inference work and performance evidence](/articles/which-gpu-is-fastest-workload-benchmarks)
- [OKE GPU host repair: interpret the dated managed workflow](/blog/oracle-oke-gpu-host-repair-workload-recovery)
- [Discuss a separate physical equipment installation](/services/turnkey-gpu-deployment)
- [Send an equipment and IT cabling project inquiry](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fgpu-kubernetes-disruption-budget-voluntary-eviction)

## Does a separately selected equipment addition need installation?

Share a nonconfidential equipment, site and IT connection outline to discuss the required physical stages, handoff records and availability.

[Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/gpu-kubernetes-disruption-budget-voluntary-eviction)