Announcing additional Extended Update Support for OpenShift 4.14 and beyond!

Red Hat is announcing an optional additional 12-month EUS term for OpenShift 4.14 and subsequent even-numbered Red Hat OpenShift releases in the 4.x series. This takes the full lifecycle available for these EUS releases of OpenShift to three (3) years.

Kicking off Red Hat Summit here in Denver with the OpenShift Commons Gathering, we will be hearing from you, our customers, who rely on Red Hat OpenShift every day.   Over the past several years, OpenShift customers have applied its technology to use cases in specialized markets that require it to have longer life cycles.  Whether due to layers of compliance requirements or the fact OpenShift is housing essential services that governments and businesses treat differently, our customers look to Red Hat to find ways to extend the life of our open source components longer.  Every year Red Hat investigates longer life cycles across a number of criteria.  This year we have found the right mix of conditions that will allow us to do something to help our customers who are in these situations.

In recognition of the complex needs of our customers, we’re expanding our Extended Update Support (EUS) offerings for Red Hat OpenShift, providing you with the option to significantly extend the supported lifecycle of OpenShift deployments.

It will extend support beyond the existing 6-month EUS term that was introduced when we released OpenShift 4.12. This new, additional 12-month EUS term will be available as an add-on subscription and takes OpenShift’s lifecycle to 3 years in total. 

With the additional EUS term, OpenShift 4.14 will now be supported through October 31, 2026:

The next Extended Update Support release will be the upcoming OpenShift 4.16 release. The impact on the lifecycle of EUS releases is also visualized below:

What level of support is included?

The additional EUS term includes backports of Critical and Important impact security updates and urgent-priority bug fixes. Formal language will be published on the Red Hat OpenShift Container Platform Lifecycle Policy page which remains the source of truth for current OpenShift lifecycle information.

The support SLA offered during the additional EUS phase will be inherited from the base offering purchased (Premium or Standard).

Which components are included?

The additional EUS term applies to all platform-aligned operators included in OpenShift Kubernetes Engine. Other operators are not automatically included and continue to maintain their own lifecycles.

A customer purchasing OpenShift Platform Plus or OpenShift Container Platform as their base subscription can still purchase the equivalent Additional Extended Update Support Term for that offering, but will only receive the additional EUS term on those components for which it is available.

We expect to offer this additional EUS term for more Red Hat operators in the future. Always check the lifecycle page for the relevant layered operator to determine the latest lifecycle information.

How does this impact upgrades?

OpenShift 4.14 maintains support for an N-2 version skew between control plane services and worker nodes, where N is the relevant OpenShift minor release. This means, for example, that a control plane that has moved forward to OpenShift 4.14 can interoperate with worker nodes on 4.13 and/or 4.12 as part of an upgrade sequence.

For the control plane nodes themselves, upgrades remain sequential in nature. For the worker nodes however, there is a facility to pause worker pools to skip every second release – and the associated reboot – which when combined with the version skew support allows for mitigation of the additional impact of multiple upgrades to running workloads. 

Example upgrade flow for control plane and worker nodes from 4.14 to a future 4.18 release.

Pending further testing this capability will be expanded in future releases in line with upstream Kubernetes version skew expansion, which is moving to supporting an N-3 version skew policy.

As the period between the source and destination release grows over time, the number of sequential upgrades required to get to the latest EUS release grows. As the number of sequential upgrades required grows, so too does the complexity of the upgrade, the level of workload disruption, and the amount of time it will take to complete. Thus if capacity allows, it may be more desirable to upgrade via a blue/green upgrade process by scaling up a new cluster, moving workloads and decommissioning the old cluster.

Every cluster is different, and thus, every cluster will require its own path to upgrading. We recommend considering and choosing an upgrade plan at the same time as you are choosing to utilize these OpenShift EUS terms for a cluster.

Where to find out more?

Red Hat has joined the Long Term Support (LTS) working group within the Kubernetes eco-system to help foster ideas around how to extend the life of Kubernetes and its related technologies.  We invite any users interested in these topics to join that community.

Learn more in the upcoming “What’s New in OpenShift 4.16” virtual event. Follow us on YouTube or Twitch to be notified of the broadcast date.

And if you’re not already an OpenShift user, and we have piqued your interest - Try It!