OpenShift Upgrade Time Calculator
Estimate an OpenShift upgrade window from operator rollout, serial control-plane updates and worker drain and reboot waves.
About OpenShift Upgrade Time Calculator
An OpenShift upgrade runs in three phases: cluster operators roll out first, then control-plane nodes update strictly one at a time to preserve etcd quorum, then the MachineConfigPool cycles workers maxUnavailable at a time. Only the worker phase parallelises, which is why the default maxUnavailable of 1 makes large clusters take so long. Upgrade windows are agreed with application owners weeks ahead, and the default serial worker rollout means a 100-node cluster takes over 28 hours at 17 minutes per node — a figure worth knowing before committing to a Saturday night.
Formula
OpenShift Upgrade Time
window = operator rollout + control-plane nodes × time per node + ceil(workers ÷ maxUnavailable) × (drain + reboot + verify).
- maxUnavailable
- Worker nodes the MachineConfigPool updates simultaneously
- drain time
- Time to evict pods while honouring PodDisruptionBudgets
- control-plane phase
- Always serial, because etcd must keep quorum throughout
Worked example
With the default values below, OpenShift Upgrade Time Calculator returns Total Upgrade Window of 8h 48m. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Worker nodesaccepts 1–2,000 nodes
- 24 nodes
- maxUnavailable in the MachineConfigPoolaccepts 1–200 nodes
- 1 nodes
- Drain time per nodeaccepts 0.5–240 minutes
- 8 minutes
- Reboot and rejoin time per nodeaccepts 0.5–120 minutes
- 6 minutes
- Verification pause per nodeaccepts 0–120 minutes
- 3 minutes
- Control-plane nodesaccepts 1–9 nodes
- 3 nodes
- Time per control-plane nodeaccepts 1–300 minutes
- 25 minutes
- Cluster operator rolloutaccepts 0–600 minutes
- 45 minutes
Results
- Total Upgrade Window
- 8h 48m
- Worker Rollout Phase
- 6h 48m
- Control-Plane Phase
- 1h 15m
- Worker Update Waves
- 24 waves
- Minutes per Wave
- 17.0 minutes
- Maintenance Window Verdict
- Fills a long maintenance window with little contingency
Step by step
- 1Values used
- 2OpenShift Upgrade Time
- 3Total Upgrade Window= 528
- 4Worker Rollout Phase= 408
- 5Control-Plane Phase= 75
- 6Worker Update Waves= 24 waves
- 7Minutes per Wave= 17.0 minutes
- 8Maintenance Window Verdict= Fills a long maintenance window with little contingency
Assumptions and limits
- The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or fees or charges into account.
- Figures are rounded for display to 1 decimal place, 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
How is OpenShift Upgrade Time calculated?
window = operator rollout + control-plane nodes × time per node + ceil(workers ÷ maxUnavailable) × (drain + reboot + verify). An OpenShift upgrade runs in three phases: cluster operators roll out first, then control-plane nodes update strictly one at a time to preserve etcd quorum, then the MachineConfigPool cycles workers maxUnavailable at a time. Only the worker phase parallelises, which is why the default maxUnavailable of 1 makes large clusters take so long.
Why does OpenShift Upgrade Time matter?
Upgrade windows are agreed with application owners weeks ahead, and the default serial worker rollout means a 100-node cluster takes over 28 hours at 17 minutes per node — a figure worth knowing before committing to a Saturday night.
What values do I need to enter?
This calculator takes 8 inputs: Worker nodes, maxUnavailable in the MachineConfigPool, Drain time per node, Reboot and rejoin time per node, Verification pause per node, Control-plane nodes, Time per control-plane node, Cluster operator rollout. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Is raising maxUnavailable safe?
It is safe as far as the platform is concerned, but it multiplies simultaneous pod evictions. Raise it only when PodDisruptionBudgets are set correctly and there is enough spare capacity to reschedule the drained pods, otherwise the drain stalls waiting for budgets it can never satisfy.
Related Calculators
- OpenShift Cluster Health Calculator
- OpenShift Registry Storage Calculator
- OpenShift Node Capacity Calculator
- Host Failure Impact Calculator
- Hypervisor Consolidation Calculator
- VMware VM Density Calculator
- OpenShift Pod Density Calculator
- OpenShift Project Quota Calculator
- OpenShift Route Capacity Calculator
- Cluster Expansion Calculator
You might also need
- OpenShift Node Capacity CalculatorCommonly used together
- Host Failure Impact CalculatorCommonly used together
- OpenShift Cluster Health CalculatorCommonly used together
- OpenShift Registry Storage CalculatorCommonly used together
- Hypervisor Consolidation CalculatorAlso in Virtualization & Private Cloud
- VMware VM Density CalculatorAlso in Virtualization & Private Cloud
