How to Use This Tool
Subtract required availability and existing unhealthy replicas before maintenance. Draining a node can stall or reduce availability when existing unhealthy replicas have already consumed the disruption margin.
Why Pod Disruption Capacity needs more than a raw total
Percentage minimum availability rounds to a whole pod, and eviction behavior depends on the live PDB plus controller state. For this page, the useful comparison is additional voluntary disruptions allowed, not whichever input happens to be largest. The Pod Disruption Capacity result answers the decision in the heading and should not be reused as a score for a different workflow.
The exact Pod Disruption Capacity formula
Allowed voluntary disruptions equal desired replicas − ceil(desired × minimum available) − unhealthy replicas, floored at zero. The visible fields are Desired application replicas, Minimum available and Currently unhealthy replicas. For Pod Disruption Capacity, read each printed unit before entry and make the values describe one transaction, cohort or reporting window. If those scopes differ, the displayed additional voluntary disruptions allowed may be arithmetically valid but operationally meaningless.
Interpreting additional voluntary disruptions allowed
Delay maintenance when the result is zero and verify the actual disruptionsAllowed field before evicting workloads. The ten-percent comparison is deliberately narrow: it tests the influence of desired application replicas and is neither a forecast nor a confidence interval. Preserve the values used, their dates and the resulting decision so a later reviewer can reproduce why Pod Disruption Capacity supported the choice.
What this Pod Disruption Capacity model leaves out
Multiple overlapping PDBs, surge replicas, involuntary failures, readiness delay and provider drain behavior are excluded. That is where Pod Disruption Capacity stops being trustworthy. If an excluded factor could reverse additional voluntary disruptions allowed, extend the model explicitly or use the authoritative account system instead of hiding the factor inside an unexplained adjustment.
Evidence and independent verification
The reference reviewed for Pod Disruption Capacity is Kubernetes — Specifying a PodDisruptionBudget. Kubernetes — Specifying a PodDisruptionBudget supports the named definition or rule but does not supply private values for additional voluntary disruptions allowed. Before acting on the result, reconcile the worked example with the relevant dashboard, invoice, export or measurement.
Private, reproducible calculation
Pod Disruption Capacity runs its arithmetic in the current browser tab and requests no login or API key. That keeps the Pod Disruption Capacity inputs away from the site's calculation server, while leaving the user responsible for detecting stale data or a changed platform rule. When an assumption changes, reopen Kubernetes — Specifying a PodDisruptionBudget and rerun the saved Pod Disruption Capacity scenario.
Sources & assumptions
Tool Spec v2 · verified 2026-08-22. Platform rules and fees can change; the editable inputs remain authoritative for your account.
Official references
- Kubernetes — Specifying a PodDisruptionBudget (checked 2026-08-22)
Model assumptions
- Every input covers the same reporting period or cohort.
- Multiple overlapping PDBs, surge replicas, involuntary failures, readiness delay and provider drain behavior are excluded.
- The calculator uses only the visible fields and does not fetch account data.
