Cluster Upgrade Time Calculator

Estimate total time to upgrade a Kubernetes cluster across control plane and nodes.

About Cluster Upgrade Time Calculator

Upgrading a cluster node-by-node (whether OS patching, kubelet version bumps, or full node replacement) involves three phases per node — draining existing pods off, performing the upgrade itself, and uncordoning plus warming back up — and only a limited number of nodes can be mid-upgrade simultaneously without violating PodDisruptionBudgets or surge capacity limits. Total time is the per-node phase sum multiplied by node count, divided by how many nodes upgrade in parallel.

Formula

totalTime = (nodes × (drainTime + upgradeTime + uncordonTime)) / parallelism

N: Total node count
t_d: Drain time per node in minutes
t_u: Upgrade time per node in minutes
t_c: Uncordon + warmup time per node in minutes
P: Nodes upgraded in parallel
T: Total upgrade time in minutes

Worked example

With the default values below, Cluster Upgrade Time Calculator returns Estimated Total Upgrade Time of 104.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

Node Countaccepts 1–100,000 nodes: 24 nodes
Drain Time per Nodeaccepts 0–1,440 minutes: 3 minutes
Upgrade Time per Nodeaccepts 0–1,440 minutes: 8 minutes
Uncordon + Warmup Time per Nodeaccepts 0–1,440 minutes: 2 minutes
Nodes Upgraded in Parallelaccepts 1–100,000 nodes: 3 nodes

Results

Estimated Total Upgrade Time: 104.0 minutes
Estimated Total Upgrade Time: 1.73 hours
Time per Node: 13.0 minutes
Sequential Batches: 8

Step by step

1Per-node time = drain + upgrade + uncordon= 13.0 min
2Batches at this parallelism= 8
3Total time = nodes × per-node time ÷ parallelism= 104.0 min

Assumptions and limits

The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

What limits upgrade parallelism in practice?

PodDisruptionBudgets on critical workloads (which cap how many replicas can be unavailable at once), available surge/spare capacity to absorb drained pods, and the managed Kubernetes provider's own node-group upgrade concurrency settings.

Why does drain time vary so much between nodes?

Nodes running pods with long terminationGracePeriodSeconds, StatefulSet pods requiring ordered shutdown, or PodDisruptionBudget conflicts that force retries all extend drain time — a node hosting mostly stateless Deployment pods drains much faster.

Should I increase parallelism to speed up upgrades?

Only as far as your PDBs and spare capacity safely allow — pushing parallelism too high risks violating availability guarantees or exhausting cluster capacity mid-upgrade if drained pods can't be rescheduled fast enough.