OpenShift 4.19 is running out of support. Do you park on 4.22 or keep going to 5.0?

OpenShift 4.19 runs out of maintenance support on December 17, and odd-numbered versions can't buy any extension. OpenShift 5.0 came out this week, so a lot of platform teams now have two questions at once. Move every 4.19 cluster to 4.20 before the deadline, then decide calmly whether it stops at 4.22 with extended support or carries on to 5.0. This guide lays out both routes, what 5.0 actually changes and the checks to run before you book a weekend.

When 4.19 support ends, nothing breaks that night. What stops is Red Hat shipping security fixes for it, and auditors and cyber insurers tend to notice an unsupported platform before anything else does. Clusters on 4.19 need a hop to 4.20 as a minimum, and that hop has its own checks.

The second decision costs more if you get it wrong. A cluster that rushes to 5.0 lands on a version whose support ends in late 2028 with nothing to buy after it. A cluster parked on 4.22 with both EUS terms is covered until mid-2029, but it skips the 5.x changes that will eventually arrive anyway. Pick per cluster, and write the reason down.

The path into 5.0 matters more than the number. Red Hat's update graph, checked on November 3, only offers 5.0 from 4.22.17 through 4.22.21, and only in the fast-5.0 and candidate-5.0 channels. The stable-5.0 channel had no 4.x entry yet. Production clusters are meant to sit on stable, eus or fast channels, so most teams will wait for stable anyway.

Red Hat's docs call the move from 4.x to 5.0 an in-place update that works like any other minor update, with no cluster rebuild and no manual data migration. The release runs Kubernetes 1.36 with the CRI-O runtime. The changes that matter for planning sit underneath: the node operating system, ingress, Helm and how operators get their permissions.

The node OS change is the one to plan around. RHCOSdefinitionRed Hat Enterprise Linux CoreOS, the operating system on every OpenShift node. 5.0 installs RHCOS 10.2 by default, and upgraded clusters keep RHCOS 9 until moved. 10.2 is optional after the upgrade, but RHCOS 9 is on a clock that runs out at 5.3, and the switch is a one-way, every-node event. Red Hat's known issues also list a 30 to 50 percent drop in throughput for messages under 4 KB on the RHEL 10 stream. Anything chatty, like a message bus or small RPC calls, needs testing on 10.2 before you move production nodes.

Ingress is the change app owners will feel first. With HAProxy moving from 2.8 to 3.2, request validation, error codes and keep-alive handling can act differently after the update. Pinning 2.8 on the 4.22 Ingress Controllers puts off the error-code and keep-alive changes, though 5.0's 2.8 build already validates requests more tightly. Update, then test 3.2 on a non-production controller. Red Hat keeps 2.8 in 5.0 only for migration and plans to remove it later.

Two more changes arrive with 5.1 but need work now. Helm v3 disappears from the CLI, so pipelines that call helm need moving to v4. And Red Hat plans to switch ReadWriteOnce and ReadWriteMany volumes to the SELinux mount option by default in 5.1. Clusters with workloads that would break get flagged and can't update until someone fixes them or opts them out.

# Run these first. They show the version, the channel and what's next
$ oc get clusterversion
$ oc adm upgrade recommend
# Log in with a token first: system:admin certificates skip the alert checks
# Pools you can pause for the 4.20 to 4.22 hop
$ oc get mcp
# HAProxy pin on each Ingress Controller (empty means 3.2 after 5.0)
$ oc get ingresscontroller -n openshift-ingress-operator -o custom-columns=NAME:.metadata.name,HAPROXY:.spec.haproxyVersion
# Switch channel when it's time
$ oc adm upgrade channel eus-4.22

Upgrades tend to break sign-in in quiet ways. Somebody can't log in to the console on Monday, a group stops mapping to a role, or a pipeline token stops working. An issue on the openshift/origin GitHub tracker reports Prometheus cookie authentication disappearing after a 4.16 patch update, which shows how small updates can still change auth behavior. Test logins and group sync on the rehearsal cluster after every hop, with a real user from each group.

5.0 also changes who holds power. OLM v1definitionThe newer Operator Lifecycle Manager that installs operators as ClusterExtension objects. In 5.0 it does this with its own cluster-admin service account. now installs every cluster extension with its own cluster-admin service account, and the per-extension service account field is ignored. Anyone allowed to create a ClusterExtension can effectively get cluster-admin software installed, so Red Hat's guidance is to control that with RBAC and validating admission policies. Check who has that right before the update, while the list is still short.

There's good news for teams using direct OIDC. The advanced authentication fields, covering custom discovery URLs, CEL claim mapping and user validation rules, are generally available in 5.0. If you held off because they needed the TechPreviewNoUpgrade feature set, which blocks updates, you can plan for them now. External claims sourcing, which pulls groups from UserInfo or Microsoft Graph when the token is too large, is still Technology Preview.

How Cohash helps: we work with your platform team through the whole climb, from the first cluster list to the last worker pool. Short of people? We can put an OpenShift administrator on contract until it's done. Read how we work on our OpenShift page, where you can also hire OpenShift engineers, look at our cloud management practice, or book an assessment. Every 4.x date is in our OpenShift support dates guide.