![](https://dw1.s81c.com//IMWUC/MessageImages/b9be5c90d85a4d1d8f55a5545dd0d693.png)
We are excited to announce the availability of OpenShift version 4.16 for your clusters that are running in Red Hat OpenShift on IBM Cloud. This marks our 15th release of OpenShift.
Our OpenShift service ensures a straightforward upgrade experience by using the IBM Cloud console, sparing you the need for extensive OpenShift expertise with just a few clicks! For more information and methods on upgrading your cluster, look here.
When you deploy new clusters, the default OpenShift version remains 4.15 (soon to be 4.16); however, you have the flexibility to opt for immediate deployment of version 4.16.
OpenShift version 4.16
In addition to all the great OpenShift features provided in this release, Red Hat OpenShift on IBM Cloud version 4.16 also includes numerous component updates that our community is excited about. Some of the highlights for the release include:
-
Reducing unauthenticated access for users or groups: There may be cases where services are exposed to the public, and anonymous users must access them without authentication. This might be for a public-facing website that allows anonymous browsing, access to an external API that doesn’t require authentication, sharing anonymized data sets with the public for research purposes, or sandbox environments that can be accessed anonymously for testing and experimentation. OpenShift 4.16 expands on the permission limitations granted to the system:anonymous
user and system:unauthenticated
group. To learn more about this, visit here.
-
Easier OpenShift update troubleshooting with oc adm upgrade status: Updating clusters can be complex, and while Red Hat OpenShift on IBM Cloud provides ease-of-use upgrade functionality through the IBM Cloud console, the oc adm
upgrade status command is also a powerful and insightful tool. The command is used to check the progress and status of an ongoing cluster upgrade. It provides information about the current phase of the upgrade, percentage completion, duration, worker and operator status, and any potential issues or errors that may be affecting the process - allowing the admin to understand whether the update is going well or if they should step in and intervene. Find out more here.
-
Boost your cluster observability with advanced monitoring and troubleshooting: A series of significant and exciting enhancements and previews have been made to OpenShift’s observability capabilities.
OpenTelemetry allows you to observe OpenShift with Kubernetes receivers, like Objects, Events, Stats, and cluster and host metrics. You’ll be able to receive logs with the FileLog and Journald receivers, cache telemetry data with the File storage extension if you’re offline or disconnected, merge signals from different mechanisms into the same processing pipeline with the forward connector, and consistently export span, metrics, and logs with the load-balancing exporter at scale. As part of this effort, the Loki exporter has also been enabled for preview, allowing you to experiment with it. Learn more here.
Distributed tracing also received some updates. As part of the Tempo Operator, the lightweight Tempo Monolithic deployment has been enabled for preview, providing a similar experience to the Jaeger All-In-One; it is ideal for troubleshooting use cases where you don’t want a sizeable attached storage. Also, as part of the Cluster Observability Operator, you can deploy the Traces UI to observe traces in the console for the first time; it coexists with the Jaeger UI shipped in Tempo and is currently visualizing scatter plots (or bubble charts) for spans, but will soon be visualizing Gantt charts.
Available through the Cluster Observability Operator, Observability signal correlation for Red Hat OpenShift expands on metrics, logs, and alerts with netflows in a new interactive panel, providing an ease-of-use way to remediate issues - reducing the meantime to detection (MTTD) and the meantime to resolution (MTTR).
-
Improved cluster health status and monitoring of OpenShift cluster operators: Components in OpenShift are prone to misconfiguration, even with Operators. And while Operators are designed for ease-of-use to automate the deployment, configuration, and management of applications or services, monitoring the health of them and the OpenShift clusters they’re installed in should extend past just their versioning. Red Hat OpenShift on IBM Cloud version 4.16 comes with exactly that. This support will monitor health at the cluster level to help our team and you to see problems - should they arise - from both the IBM Cloud CLI and the IBM Cloud Console.
To see the full list of IBM and Red Hat enhancements, visit Red Hat OpenShift 4.16: What you need to know and Red Hat OpenShift on IBM Cloud version 4.16 change log for more details.
OpenShift version support updates
Now that Red Hat OpenShift on IBM Cloud supports OpenShift version 4.16, clusters running version 4.12 or 4.13 are now deprecated with end of support tentatively scheduled for February 26, 2025. It is important to note clusters that run a deprecated OpenShift version may not receive fixes for security vulnerabilities until they are updated to a non-deprecated version.
As a reminder, if your cluster runs a deprecated or unsupported OpenShift version, review the potential impact of each OpenShift version update, and update today. If your cluster runs an archived OpenShift version, create a new cluster and deploy your apps to the new cluster. Here is the current support status for Red Hat OpenShift on IBM Cloud clusters running an earlier OpenShift version:
-
Clusters running OpenShift version 4.11 remain unsupported with end of support reached on March 6, 2024. Such clusters will not receive fixes for security vulnerabilities until they are updated to a deprecated or supported version.
-
Clusters running OpenShift version 4.10 or earlier remain archived. For security reasons, IBM reserves the right to shutdown the control planes of such clusters.
For general questions, engage our team via Slack by joining the discussion in the #general or #openshift channels on our public Slack.