Cluster Upgrade Time Calculator
Estimate total time to upgrade every node in a cluster from per-node drain, upgrade and uncordon times, and the upgrade parallelism.
Inputs
OS/kubelet upgrade or node replacement time.
Max nodes undergoing upgrade simultaneously (bounded by PodDisruptionBudgets and surge settings).
Estimated Total Upgrade Time
104.0minutes
Estimated Total Upgrade Time
1.73hours
Time per Node
13.0minutes
Sequential Batches
8
Step by step
Per-node time = drain + upgrade + uncordon
3 + 8 + 2
= 13.0 min
Batches at this parallelism
ceil(24 ÷ 3)
= 8
Total time = nodes × per-node time ÷ parallelism
24 × 13.0 ÷ 3
= 104.0 min
How it works
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
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.
You might also need
- Cluster Autoscaler CalculatorCommonly used together
- Cluster Health Score CalculatorCommonly used together
- Job Completion Time CalculatorCommonly used together
- Rolling Update Duration CalculatorCommonly used together
- CronJob Schedule CalculatorCommonly used together
- API Server Request CalculatorCommonly used together