Chapter 1. OpenShift Container Platform 4.17 release notes

By default, the installation process creates a Cluster Resource Override Operator pod on a worker node and two Cluster Resource Override pods on control plane nodes. You can move these pods to other nodes, such as an infrastructure node, as needed. For more information, see Moving the Cluster Resource Override Operator pods.

The Cluster Resource Override Operator pod is now owned by a deployment object. Previously, the Operator was owned by a daemon set object. Using a deployment for the Operator addresses a number of issues, including additional security and add the ability to run the pods on worker nodes.

The documentation for OLM v1, which has been in Technology Preview starting in OpenShift Container Platform 4.14, is now moved and reworked as a separate guide called Extensions. Previously, OLM v1 documentation was a subsection of the existing Operators guide, which otherwise documents the existing OLM feature set.

The updated location and guide name reflect a more focused documentation experience and aims to differentiate between OLM v1 and existing OLM.

This Technology Preview phase of OLM v1 introduces the following features:

Currently, Operator Lifecycle Manager (OLM) v1 supports installing cluster extensions that meet all of the following criteria:

OLM v1 checks that the extension you want to install meets these constraints. If the extension that you want to install does not meet these constraints, an error message is printed in the cluster extension’s conditions.

Operator Lifecycle Manager (OLM) v1 does not support the OperatorConditions API introduced in existing OLM.

If an extension relies on only the OperatorConditions API to manage updates, the extension might not install correctly. Most extensions that rely on this API fail at start time, but some might fail during reconciliation.

As a workaround, you can pin your extension to a specific version. When you want to update your extension, consult the extension’s documentation to find out when it is safe to pin the extension to a new version.

You can now configure host firmware settings for managed clusters that you deploy with GitOps ZTP. You save host profile YAML files alongside SiteConfig custom resources (CRs) that you use to deploy the managed clusters. GitOps ZTP uses the host profiles to configure firmware settings in the managed cluster hosts during deployment. On the hub cluster, you can use FirmwareSchema CRs to discover managed cluster host firmware schema, and HostFirmwareSettings CRs and retrieve managed clusters firmware settings.

For more information, see Managing host firmware settings with GitOps ZTP.

With this release, the image-based upgrade introduces the following enhancements:

For more information about the ImageBasedGroupUpgrade API, see Managing the image-based upgrade at scale using the ImageBasedGroupUpgrade CR on the hub.

With this release, you can enable disk encryption with Trusted Platform Module (TPM) and Platform Configuration Registers (PCRs) protection. You can use the diskEncryption field in the SiteConfig custom resource (CR) to configure the disk encryption. Configuring the SiteConfig CR enables disk encryption at the time of cluster installation.

For more information, see Enabling disk encryption with TPM and PCR protection.

You can now enable IPsec encryption in managed multi-node clusters that you deploy with GitOps ZTP and Red Hat Advanced Cluster Management (RHACM). You can encrypt traffic between the managed cluster and IPsec endpoints external to the managed cluster. All network traffic between nodes on the OVN-Kubernetes cluster network is encrypted with IPsec in Transport mode.

For more information, see Configuring IPsec encryption for multi-node clusters using GitOps ZTP and SiteConfig resources.

Image-based installations streamline the installation and deployment process for single-node OpenShift clusters by significantly reducing installation and deployment times.

Using an image-based workflow, you can preinstall instances of single-node OpenShift on target hosts. These preinstalled hosts can be rapidly reconfigured and deployed at the far edge of the network, including in disconnected environments, with minimal intervention.

For more information, see Understanding an image-based installation and deployment for single-node OpenShift clusters.

The IBM Z® and IBM® LinuxONE release on OpenShift Container Platform 4.17 adds improvements and new capabilities to OpenShift Container Platform components and concepts.

This release introduces support for the following features on IBM Z® and IBM® LinuxONE:

The IBM Power® release on OpenShift Container Platform 4.17 adds improvements and new capabilities to OpenShift Container Platform components.

This release introduces support for the following features on IBM Power:

This release introduces a new feature called Rapid Recommendations, which provides a more dynamic and version-independent mechanism for remotely configuring the rules that determine which data the Insights Operator collects.

Rapid Recommendations builds on the existing conditional data gathering mechanism. The Insights Operator connects to a secure remote endpoint service running on /console.redhat.com to retrieve definitions that contain the rules for determining which container log messages are filtered and collected by Red Hat.

The conditional data-gathering definitions, also referred to as rules, get configured through an attribute named conditionalGathererEndpoint in the pod.yml configuration file.

conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules

conditionalGathererEndpoint: https://console.redhat.com/api/gathering/v2/%s/gathering_rules

The preconfigured endpoint URL now provides a placeholder (%s) for defining a target version of OpenShift Container Platform.

The Insights Operator now gathers more data to detect the following scenarios, which other applications can use to generate remedial recommendations to proactively manage your OpenShift Container Platform deployments:

With this update, the user-defined labels and tags for Google Cloud Platform (GCP) is Generally Available.

For more information, see Managing user-defined labels and tags for GCP.

With this update, you can install a cluster on Nutanix with compute machines that use GPUs for processing. You attach a GPU to compute nodes with the compute.platform.nutanix.gpus parameters in the install-config.yaml file.

For more information, see Installation configuration parameters for Nutanix.

With this update, you can install a cluster on Nutanix with compute machines that have multiple disks attached to them. You attach multiple disks to compute nodes with the compute.platform.nutanix.dataDisks parameters in the install-config.yaml file.

For more information, see Installation configuration parameters for Nutanix.

You can now install an OpenShift Container Platform cluster on Azure in the Central Spain region, spaincentral.

For more information, see Supported Azure regions.

With this release, you can install an Amazon Web Services (AWS) cluster and Google Cloud Platform (GCP) cluster with the support for configuring multi-architecture compute machines. While installing the cluster, you can specify different CPU architectures for the control plane and compute machines in the following ways:

An OpenShift Container Platform cluster with multi-architecture compute machines supports compute machines with different architectures. For more information, see the following documentation:

In OpenShift Container Platform 4.17, you can install a cluster on Nutanix with Flow Virtual Networking enabled. Flow Virtual Networking is a software-defined networking solution for Nutanix AHV clusters that provides multi-tenant isolation, self-service provisioning, and IP address preservation using VPCs, subnets, and other virtual components that are separate from the physical network. To perform this installation, enable Flow Virtual Networking in your Nutanix AHV environment before installing.

For more information, see Flow Virtual Networking overview.

In OpenShift Container Platform 4.17, the installation program uses Cluster API instead of Terraform to provision cluster infrastructure during installations on Azure.

With this update, you can install a cluster on GCP by using an existing service account, allowing you to minimize the permissions that you grant to the service account the installation program uses. You can specify this service account in the compute.platform.gcp.serviceAccount and controlPlane.platform.gcp.serviceAccount parameters in the install-config.yaml file. For more information, see Available installation configuration parameters for GCP.

With this release, you can install OpenShift Container Platform on Amazon Web Services (AWS) by using an existing identity and access management (IAM) instance profile. For more information, see Optional AWS configuration parameters.

With this release, you can deploy a cluster on GCP using the N4 machine series for compute or control plane machines. The supported disk type of N4 machine series is hyperdisk-balanced. For more information, see Installation configuration parameters for GCP.

With this release, the installation program uses Cluster API instead of Terraform to provision cluster infrastructure during installations on GCP.

Deploying a three-node cluster on installer-provisioned infrastructure is now supported on Red Hat OpenStack Platform (RHOSP).

For more information, see Installing a three-node cluster on OpenStack.

You can now move etcd from a root volume (Cinder) to a dedicated ephemeral local disk as a Day 2 deployment with this generally available feature.

For more information, see Deploying on OpenStack with rootVolume and etcd on local disk.

For release notes about OLM v1 in OpenShift Container Platform 4.17 and later, including its new guide location starting this release, see the new features and enhancements section for Extensions (OLM v1).

This "Operator lifecycle" section will continue to document new features and enhancements for existing OLM in future releases.

When deprecated packages, channels, or versions are defined for Operators in a catalog, the OpenShift Container Platform web console now displays warning badges for the affected elements of the Operator, including any custom deprecation messages, on both the pre- and post-installation pages of the OperatorHub.

For more information on the deprecation schema for Operator catalogs, see see Operator Framework packaging format Schemas olm.deprecations schema.

With this release, Operators managed by Operator Lifecycle Manager (OLM) can support token authentication when running on Google Cloud Platform (GCP) clusters configured for GCP Workload Identity. Updates to the Cloud Credential Operator (CCO) enable semi-automated provisioning of certain short-term credentials, provided that the Operator author has enabled their Operator to support GCP Workload Identity.

For more information, see CCO-based workflow for OLM-managed Operators with GCP Workload Identity.

With this release, oc-mirror now includes the Red Hat Enterprise Linux CoreOS (RHCOS) image for the HyperShift KubeVirt provider when mirroring the OpenShift Container Platform release payload.

The kubeVirtContainer flag, which is set to false by default, must be set to true in the imageSetConfig.yaml file to extract the KubeVirt Container RHCOS. This ensures support for disconnected environments by including the required image for KubeVirt virtual machines acting as nodes for hosted clusters.

The Machine Config Operator (MCO) and Machine Config Server now use the TLS security profile that is configured for the control plane components. For more information, see Configuring the TLS security profile for the control plane.

Updated boot images are now supported as a Technology Preview feature for Amazon Web Services (AWS) clusters. This feature allows you configure your cluster to update the node boot image whenever you update your cluster. By default, the boot image in your cluster is not updated along with your cluster. For more information, see Updated boot images.

Updated boot images has been promoted to GA for Google Cloud Platform (GCP) clusters. For more information, see Updated boot images.

The node disruption policies feature has been promoted to GA. A node disruption policy allows you to define a set of Ignition config objects changes that would require little or no disruption to your workloads. For more information, see Using node disruption policies to minimize disruption from machine config changes.

This release introduces the placementGroupPartition field for OpenShift Container Platform MachineSet on Amazon Web Services (AWS). With this feature, you can specify a partition number within an existing placement group, enabling precise instance allocation and improved fault tolerance. For example, see Assigning machines to placement groups for Elastic Fabric Adapter instances by using machine sets.

OpenShift Container Platform release 4.17 introduces support for on-demand Capacity Reservation with Capacity Reservation groups on Microsoft Azure clusters. For more information, see Configuring Capacity Reservation by using machine sets for compute or control plane machine sets.

This release includes the following version updates for in-cluster monitoring stack components and dependencies:

With this update, the Prometheus configuration for monitoring for user-defined projects now tolerates jitters at scrape time. This update optimizes data compression for monitoring deployments that show sub-optimal chunk compression for data storage, which reduces the disk space used by the time series database in these deployments.

The Network Observability Operator releases updates independently from the OpenShift Container Platform minor version release stream. Updates are available through a single, Rolling Stream which is supported on all currently supported versions of OpenShift Container Platform 4. Information regarding new features, enhancements, and bug fixes for the Network Observability Operator is found in the Network Observability release notes.

Beginning in OpenShift Container Platform 4.17, when a node is rebooted, the crio wipe command checks that the CRI-O binary exited cleanly. Those images that did not exit cleanly are targeted as corrupted and removed. This behavior prevents CRI-O from failing to start due to half-pulled images or other unsynced files. In OpenShift Container Platform 4.15 and 4.16, the crio wipe command removed all images when a node was rebooted. The crio wipe command’s new behavior increases efficiency while still reducing the risk of image corruption when a node is rebooted.

OpenShift Container Platform release 4.17 adds two new flags for use with the oc adm must-gather command to limit the timespan of the information gathered. Only one of the following flags can be used at a time. Plugins are encouraged but not required to support these flags.

For a full list of flags to use with the oc adm must-gather command, see Must-gather flags.

OpenShift Container Platform release 4.17 adds support for deploying pods and containers into Linux user namespaces. Running pods and containers in individual user namespaces can mitigate several vulnerabilities that a compromised container can pose to other pods and the node itself. For more information, see Running pods in Linux user namespaces.

OpenShift Container Platform monitoring now uses a TLS-backed endpoint to fetch CRI-O container runtime metrics. These certificates are managed by the system and not the user. OpenShift Container Platform monitoring queries have been updated to the new port. For information on the certificates used by monitoring, see Monitoring and OpenShift Logging Operator component certificates.

With this release, you can add compute nodes by using the OpenShift CLI (oc) to generate an ISO image, which can then be used to boot one or more nodes in your target cluster. This process can be used regardless of how you installed your cluster.

For more information, see Adding worker nodes to an on-premise cluster.

You can now configure linuxptp services as a grandmaster clock (T-GM) for dual Intel E810 Logan Beach network interface controllers (NICs). You can configure the linuxptp services as a T-GM for the following dual E810 NICs:

The host system clock is synchronized from the NIC that is connected to the Global Navigation Satellite Systems (GNSS) time source. The second NIC is synced to the 1PPS timing output provided by the NIC that is connected to GNSS. For more information, see Configuring linuxptp services as a grandmaster clock for dual E810 NICs.

For OpenShift Container Platform 4.17 and later versions, clusters use 169.254.0.0/17 for IPv4 and fd69::/112 for IPv6 as the default masquerade subnet. These ranges should be avoided by users. For upgraded clusters, there is no change to the default masquerade subnet. For information on how to change the masquerade subnet as a Day 2 operation, see Configuring the OVN-Kubernetes masquerade subnet as a Day 2 operation

With this release, you can query the Single Root I/O Virtualization (SR-IOV) virtual function (VF) metrics by using the OpenShift Container Platform web console to monitor the networking activity of the SR-IOV pods. When you query the SR-IOV VF metrics by using the web console, the SR-IOV network metrics exporter fetches and returns the VF network statistics along with the name and namespace of the pod that the VF is attached to.

For more information, see Enabling the SR-IOV network metrics exporter.

With this release, MetalLB includes a new field for the Border Gateway Protocol (BGP) peer custom resource. You can use the dynamicASN field to detect the Autonomous System Number (ASN) to use for the remote end of a BGP session. This is an alternative to explicitly setting an ASN in the spec.peerASN field.

Red Hat support exists for using the Kubernetes NMState Operator on Microsoft Azure but in a limited capacity. Support is limited to configuring DNS servers on your system as a postinstallation task.

For more information, see About the Kubernetes NMState Operator.

The Kubernetes NMState Operator, kubernetes-nmstate-operator, can collect metrics from the kubernetes_nmstate_features_applied component and expose them as ready-to-use metrics. You can view these metrics by using the Administrator and Developer perspectives.

For more information, see About the Kubernetes NMState Operator.

A new PTP fast events O-RAN Release 3 compliant REST API version 2 is available. Now, you can develop PTP event consumer applications that receive host hardware PTP events directly from the PTP Operator-managed pod.

The PTP events REST API v1 and PTP events consumer application sidecar is deprecated.

For more information, see Developing PTP event consumer applications with the REST API v2.

The PTP Operator now automatically updates the leap second file by using Global Positioning System (GPS) announcements.

Leap second information is stored in an automatically generated ConfigMap resource named leap-configmap in the openshift-ptp namespace.

For more information, see Configuring dynamic leap seconds handling for PTP grandmaster clocks.

With this update, the ability to enable NIC partitioning for Single Root I/O Virtualization (SR-IOV) devices at install time is Generally Available.

For more information, see NIC partitioning for SR-IOV devices.

With this update, the ability to update host network settings for Single Root I/O Virtualization (SR-IOV) network virtual functions in an existing cluster is Generally Available.

For more information, see Node network configuration policy for virtual functions.

With OpenShift Container Platform 4.17, users can create multiple networks and declare them as primary or secondary networks for their workloads through the technology preview of the UserDefinedNetwork (UDN) custom resource definition (CRD). With UDN, users can isolate namespaces without configuring and managing complex network policies.

For more information, see Understanding user-defined networks

OpenShift Container Platform 4.17 now includes CoreDNS version 1.11.3.

The eBPF manager Operator, available as a Technology Preview, allows you to securely deploy and manage eBPF programs. It facilitates the secure loading, unloading, modifying, and monitoring of eBPF programs in OpenShift Container Platform clusters. For more information about deploying the bpfman Operator, see About the eBPF Manager Operator.

Secure management of eBPF programs for the Ingress Node Firewall Operator is available as a Technology Preview. Use of this feature requires installation of the eBPF manager Operator, also available as a Technology Preview. For more information, see Ingress Node Firewall Operator integration.

With this update, MetalLB uses FRR-K8s as the default backend. Previously, this was an optional feature available in Technology Preview. For more information, see Configuring the integration of MetalLB and FRR-K8s.

MetalLB also includes a new field for the Border Gateway Protocol (BGP) peer custom resource, connectTime. You can use this field to specify how long BGP waits between connection attempts to a neighbor. For more information, see About the BGP peer custom resource.

With this release, maximum transmission unit (MTU) on virtual function using the vfio-pci driver is available in the network-status pod annotation, and inside the container.

For more information, see Exposing MTU for vfio-pci SR-IOV devices to pod.

With this release, the naming convention for MetalLB BGP and BFD metrics was updated:

To view all the metrics in the new format, see MetalLB metrics for BGP and BFD.

A new, optional configuration parameter, chunkSizeMiB, is now available for deployments using S3 API-compatible backend storage. When configured, it determines the size of the multipart upload chunks for the S3 API. The default value is 10 MiB, with a minimum of 5 MiB.

For more information, see Image Registry Operator configuration parameters for AWS S3.

RHCOS uses Red Hat Enterprise Linux (RHEL) 9.4 packages in OpenShift Container Platform 4.17. These packages ensure that your OpenShift Container Platform instance receives the latest fixes, features, enhancements, hardware support, and driver updates.

With this release, you can now use DNF to install additional packages to your customized Red Hat Enterprise Linux CoreOS (RHCOS) builds. For more information, see Red Hat Enterprise Linux CoreOS (RHCOS) image layering.

Amazon Web Services (AWS) Elastic File Service (EFS) usage metrics allow you to monitor how much space is used by EFS volumes. This feature is generally available.

For more information, see AWS EFS storage CSI usage metrics.

Previously, there was no validation of whether the mode of an original volume (filesystem or raw block), whose snapshot was taken, matches the mode of a newly created volume. This presented a security gap that could allow malicious users to potentially exploit an as-yet-unknown vulnerability in the host operating system.

Nevertheless, some users have a legitimate need to perform such conversions. This feature allows cluster administrators to provide these rights (ability to perform update or patch operations on VolumeSnapshotContents objects) only to trusted users or applications, such as backup vendors.

To convert a volume mode, an authorized user needs to change snapshot.storage.kubernetes.io/allow-volume-mode-change: "true" for VolumeSnapshotContent of the snapshot source.

This feature is supported as generally available.

In earlier versions of OpenShift Container Platform, when destroying a cluster, Google Compute Platform (GCP) Filestore Storage did not delete all of the cloud resources belonging to that cluster. This required manually deleting all of the persistent volume claims (PVCs) that used the Filestore storage class before destroying the cluster.

With OpenShift Container Platform 4.17, when destroying a cluster the OpenShift Container Platform installer should generally delete all of the cloud resources that belong to that cluster, and therefore manual deletion of PVCs should not be required. However, due to the special nature of the Google Compute Platform (GCP) Filestore resources, the automated cleanup process might not remove all of the resources in some rare cases. This feature is supported as generally available.

For more information, see Destroying clusters and GCP Filestore.

OpenShift Container Platform 4.17 introduces volume snapshot support for the Microsoft Azure File Container Storage Interface (CSI) Driver Operator. This capability is supported as a Technology Preview feature.

For more information, see CSI drivers supported by OpenShift Container Platform and CSI volume snapshots.

OpenShift Container Platform v4.17 introduces the ability to deploy OpenShift Container Platform across multiple vSphere clusters (vCenters). This feature is supported with Technology Preview status.

Multiple vCenters can only be configured during installation. The maximum number of supported vCenter clusters is three.

For more information, see Multiple vCenter support for vSphere CSI and Installation configuration parameters for vSphere.

Cluster administrators might want to disable the VMWare vSphere Container Storage Interface (CSI) Driver as a Day 2 operation, so the vSphere CSI Driver does not interface with your vSphere setup. This feature is supported at the Technology Preview level.

For more information, see Disabling and enabling storage on vSphere.

Pods might take a very long time to start when the volume contains a large number of files. To avoid SELinux labeling issues while keeping SELinux confining, you can enable the ReadWriteMany/ReadWriteOnce (RWX/RWO) SELinux Mount feature. Be advised that the RWX/RWO SELinux Mount feature is a Developer Preview feature. It is not supported by Red Hat, and you should not enable this feature set on production or clusters that you plan to maintain over time.

For more information about the RWX/RWO SELinux Mount feature, including how to enable it, see RWX/RWO SELinux Mount feature Knowledge Centered Service article.

In OpenShift Container Platform 4.17, if you are running out of space in your current datastore, or want to move to a more performant datastore, you can migrate volumes between datastores. Be advised that this feature is a Developer Preview feature. It is not supported by Red Hat.

For more information about cns-migration, see Moving CNS volumes between datastores.

You can now use the Secrets Store CSI Driver Operator to mount secrets from Google Secret Manager to a Container Storage Interface (CSI) volume in OpenShift Container Platform. The Secrets Store CSI Driver Operator is available as a Technology Preview feature.

For the full list of available secrets store providers, see Secrets store providers.

For information about using the Secrets Store CSI Driver Operator to mount secrets from Google Secret Manager, see Mounting secrets from Google Secret Manager.

In this release, the firmware search path has been updated to copy the contents of the specified path into the path specified in worker.setFirmwareClassPath (default: /var/lib/firmware). For more information, see Example Module CR.

In this release, if your cluster is installed on a bare metal platform, you can scale a cluster control plane up to 5 nodes as a postinstallation task. The etcd Operator scales accordingly to account for the additional control plane nodes. For more information, see Node scaling for etcd.

From release 4.17.10, you can use the PerformanceProfile custom resource (CR) to configure compute nodes on machines equipped with AMD EPYC Zen 4 CPUs, such as Genoa and Bergamo. Only single NUMA domain (NPS=1) configurations are supported. Per-pod power management is currently not supported on AMD.

With this release, all etcd certificates originate from a new namespace: openshift-etcd. When a new signer certificate is close to its expiration date, the following actions occur:

Manual rotation of signer certificates is still supported by deleting the specific secret and waiting for the status pod rollout to complete.

With this release, Technology Preview clusters use Sigstore signatures to verify images that were retrieved using a pull spec that references the quay.io/openshift-release-dev/ocp-release repository.

Currently, if you are mirroring images, you must also mirror quay.io/openshift-release-dev/ocp-release:<release_image_digest_with_dash>.sig Sigstore signatures in order for the image verification to succeed.

Starting with OpenShift Container Platform 4.16, OpenShift Lightspeed Operator is available for use in the web console. With this release, a hover button was added to help you discover OpenShift Lightspeed. Once you click the hover button, the chat window appears with instructions on how to enable and install OpenShift Lightspeed on the cluster. You can hide the OpenShift Lightspeed button when changing the default user preferences.

This release introduces the following updates to the Administrator perspective of the web console:

This release introduces the following updates to the Developer perspective of the web console:

With this release, extending compute nodes into AWS Outposts for clusters deployed on AWS Public Cloud is deprecated. The ability to deploy compute nodes into AWS Outposts after installation, as an extension of an existing OpenShift Container Platform cluster operating in a public AWS region, will be removed with the release of OpenShift Container Platform version 4.20.

For more information, see Extending an AWS VPC cluster into an AWS Outpost.

The preserveBootstrapIgnition parameter for AWS in the install-config.yaml file has been deprecated. You can use the bestEffortDeleteIgnition parameter instead. (OCPBUGS-33661)

In OpenShift Container Platform 4.17, kube-apiserver no longer gets a valid cloud configuration object. As a result, the PersistentVolumeLabel admission plugin rejects in-tree Google Compute Engine (GCE) persistent disk persistent volumes (PD PVs), that do not have the correct topology. (OCPBUGS-34544)

In OpenShift Container Platform 4.16, Patternfly 4 and React Router 5 were deprecated. The deprecated static remains the same for OpenShift Container Platform 4.17. All plugins should migrate to Patternfly 5 and React Router 6 as soon as possible. (OCPBUGS-34538)

OpenShift SDN network plugin was deprecated in 4.15 and 4.16. With this release, the SDN network plugin is no longer supported and the content has been removed from the documentation.

RukPak was introduced as a Technology Preview feature in OpenShift Container Platform 4.12. Starting in OpenShift Container Platform 4.14, it was used as a component in the Technology Preview of Operator Lifecycle Manager (OLM) v1.

Starting in OpenShift Container Platform 4.17, RukPak is now removed and relevant functionality relied upon by OLM v1 has been moved to other components.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.

To update an OpenShift Container Platform 4.17 cluster to this latest release, see Updating a cluster using the CLI.