Skip to content
ENExplore Calculators

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

  1. 1Values used
  2. 2OpenShift Upgrade Time
  3. 3Total Upgrade Window= 528
  4. 4Worker Rollout Phase= 408
  5. 5Control-Plane Phase= 75
  6. 6Worker Update Waves= 24 waves
  7. 7Minutes per Wave= 17.0 minutes
  8. 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.

OpenShift Upgrade Time Calculator | Calcrivo