Skip to content
Calcrivo

OpenShift Upgrade Time Calculator

Estimate an OpenShift upgrade window from operator rollout, serial control-plane updates and worker drain and reboot waves.

Inputs

nodes
nodes

Defaults to 1, so workers update strictly one at a time.

minutes

Dominated by PodDisruptionBudgets and slow terminationGracePeriodSeconds.

minutes
minutes
nodes
minutes

Control-plane nodes always update serially to preserve etcd quorum.

minutes

Total Upgrade Window

8h 48m

Worker Rollout Phase

6h 48m

Control-Plane Phase

1h 15m

Worker Update Waves

24waves

Minutes per Wave

17.0minutes

Maintenance Window Verdict

Fills a long maintenance window with little contingency

Step by step

  1. Values used

    Worker nodes = 24 nodes; maxUnavailable in the MachineConfigPool = 1 nodes; Drain time per node = 8 minutes; Reboot and rejoin time per node = 6 minutes; Verification pause per node = 3 minutes; Control-plane nodes = 3 nodes; Time per control-plane node = 25 minutes; Cluster operator rollout = 45 minutes

  2. OpenShift Upgrade Time

    window = operator rollout + control-plane nodes × time per node + ceil(workers ÷ maxUnavailable) × (drain + reboot + verify).

  3. Total Upgrade Window

    = 528

  4. Worker Rollout Phase

    = 408

  5. Control-Plane Phase

    = 75

  6. Worker Update Waves

    = 24 waves

  7. Minutes per Wave

    = 17.0 minutes

  8. Maintenance Window Verdict

    = Fills a long maintenance window with little contingency

How it works

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

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.

You might also need