Estimate an OpenShift upgrade window from operator rollout, serial control-plane updates and worker drain and reboot waves.
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.
OpenShift Upgrade Time
window = operator rollout + control-plane nodes × time per node + ceil(workers ÷ maxUnavailable) × (drain + reboot + verify).
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.
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.
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.
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.