OpenShift 4.22: upgrading from 4.18 EUS step by step

Published 2 October 2026 · Updated 2 October 2026

In short. From 4.18 EUS you reach 4.22 with two Control Plane Only updates: 4.18, 4.19, 4.20, then 4.20, 4.21, 4.22. Minor versions are serialised and EUS-to-EUS applies only between even-numbered versions. 4.18 has EUS Term 1 until 25 February 2027.

OpenShift Container Platform 4.22 has been available since 9 June 2026 and is based on Kubernetes 1.35, with RHCOS on RHEL 9.8 packages. Source: Red Hat Product Life Cycles and 4.22 release notes.

Why now

Version GA End of full support End of maintenance EUS
4.18 25 February 2025 17 September 2025 25 August 2026 Term 1 until 25 February 2027
4.20 21 October 2025 3 May 2026 21 April 2027 Term 1 until 21 October 2027
4.22 9 June 2026 31 December 2026 31 December 2027 Term 1 until 30 June 2028

As of 2 October 2026, 4.18 has reached the end of maintenance and is covered only by extended update support (EUS) until 25 February 2027, which depends on the subscription type. Source: update policy.

The path

Minor versions are upgraded one at a time: you cannot jump from 4.y to 4.y+2. Between even-numbered versions, Red Hat offers the Control Plane Only update (formerly EUS-to-EUS), which keeps the worker node machine config pools paused. The path derived from the rules is:

  1. 4.18 → 4.19 → 4.20 with the worker nodes paused, then upgrade the nodes to 4.20.
  2. 4.20 → 4.21 → 4.22 with a second Control Plane Only update, then the nodes to 4.22.

The eus channel exists only for even-numbered versions and is a convenience for this type of update. Source: update documentation.

Checks before each jump

  • 4.18 → 4.19: explicit administrator acknowledgement is required for removed APIs.
  • 4.19 → 4.20: acknowledgement for the removal of a Kubernetes API that was reintroduced by mistake in 4.17.
  • 4.21: requires vSphere 8 Update 1 or later; swap and the Operator SDK scaffolding are removed.
  • 4.21 → 4.22 on Azure and vSphere: the update is blocked until boot image management is explicitly enabled or disabled.
  • Operators: check compatibility with the target version (olm.maxOpenShiftVersion annotation).
  • Console plugins: the console requires React 18, Redux 5 and PatternFly 6.
  • etcd backup and the ClusterNotUpgradeable alert, which blocks minor updates if operators are not ready.
  • OpenShift SDN cannot be upgraded to 4.17 or later: migration to OVN-Kubernetes is needed first.

Risks of pausing nodes

With the pools paused, the cluster cannot move to later minor versions, some maintenance operations are inhibited and rotated certificates do not reach the paused nodes. If a problem appears on the odd-numbered version, the fix may require updating the nodes. Keep pauses short and do not update the pools to different versions.

Tools

The oc adm upgrade recommend command (available from 4.20) performs read-only checks before the update. The OpenShift Update Service publishes the update graph and flags paths that are not recommended.

What has not been verified

I could not read the Update Graph tool (it requires access to the customer portal), nor verify that all the update edges in the channels exist today, nor the full list of 4.22 removals. Check with oc adm upgrade on your own cluster.

To plan the upgrade with a rehearsal on a test cluster, see Red Hat OpenShift Container Platform.

Need a hand?

If you want to apply these points to your case, tell me in a few lines.

Let's talk