Chapter 1. OpenShift Container Platform 4.19 release notes

With this release, you can enable direct integration with an external OpenID Connect (OIDC) identity provider to issue tokens for authentication. This bypasses the built-in OAuth server and uses the external identity provider directly.

By integrating directly with an external OIDC provider, you can leverage the advanced capabilities of your preferred OIDC provider instead of being limited by the capabilities of the built-in OAuth server. Your organization can manage users and groups from a single interface, while also streamlining authentication across multiple clusters and in hybrid environments. You can also integrate with existing tools and solutions.

Direct authentication is available as a Technology Preview feature.

For more information, see Enabling direct authentication with an external OIDC identity provider.

In OpenShift Container Platform 4.19, the ServiceAccountTokenNodeBinding feature is now enabled by default, aligning with upstream Kubernetes behavior. This feature allows service account tokens to be bound directly to node objects in addition to the existing binding options. Benefits of this change include enhanced security through automatic token invalidation when bound nodes are deleted and better protection against token replay attacks across different nodes.

This release includes an etcd section, which consolidates all of the existing documentation about etcd for OpenShift Container Platform. For more information, see Overview of etcd.

OpenShift Container Platform 4.19 now includes a Tutorials guide, which takes the place of the Getting started guide in previous releases. The existing tutorials were refreshed and the guide now focuses solely on hands-on tutorial content. It also provides a jumping off point to other recommended hands-on learning resources for OpenShift Container Platform across Red Hat.

For more information, see Tutorials.

You can now use PolicyGenerator resources and Red Hat Advanced Cluster Management (RHACM) to deploy polices for managed clusters with GitOps ZTP. The PolicyGenerator API is part of the Open Cluster Management standard and provides a generic way of patching resources, which is not possible with the PolicyGenTemplate API. Using PolicyGenTemplate resources to manage and deploy polices will be deprecated in an upcoming OpenShift Container Platform release.

For more information, see Configuring managed cluster policies by using PolicyGenerator resources.

You can configure an OpenShift Container Platform cluster with two control plane nodes and one local arbiter node so to retain high availability (HA) while reducing infrastructure costs for your cluster. This configuration is only supported for bare-metal installations.

A local arbiter node is a lower-cost, co-located machine that participates in control plane quorum decisions. Unlike a standard control plane node, the arbiter node does not run the full set of control plane services. You can use this configuration to maintain HA in your cluster with only two fully provisioned control plane nodes instead of three.

To enable this feature, you must define the arbiter machine pool in the install-config.yaml file and enable the TechPreviewNoUpgrade feature set. For more information, see Configuring a local arbiter node.

This release adds reboot policies to ZTP reference that can be applied by Topology Aware Lifecycle Manager (TALM) to coordinate reboots across a fleet of spoke clusters when configuration changes require a reboot, such as deferred tuning changes. TALM reboots all nodes in the targeted MachineConfigPool object on the selected clusters when the reboot policy is applied.

Instead of rebooting nodes after each individual change, you can apply all configuration updates through policies and then trigger a single, coordinated reboot.

For more information, see Coordinating reboots for configuration changes.

With this release, the Operator Controller performs a dry run of the installation process when you try to install an extension. This dry run verifies that the specified service account has the required role-based access control (RBAC) rules for the roles and bindings defined by the bundle.

If the service account is missing any required RBAC rules, the preflight check fails before the actual installation proceeds and generates a report.

For more information, see Preflight permissions check for cluster extensions (Technology Preview)

With this release, you can deploy an extension in a specific namespace by using the OwnNamespace or SingleNamespace install modes as a Technology Preview feature for registry+v1 Operator bundles.

For more information, see Deploying a cluster extension in a specific namespace (Technology Preview)

Hosted control planes on RHOSP 17.1 are now supported as a Technology Preview.

For more information, see Deploying hosted control planes on OpenStack.

In OpenShift Container Platform 4.18, the Insights Operator introduced the Insights Runtime Extractor workload data collection feature as a Technology Preview feature to help Red Hat better understand the workload of your containers. Now, in version 4.19, the feature is generally available. The Insights Runtime Extractor feature gathers runtime workload data and sends it to Red Hat.

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

You can now install an OpenShift Container Platform cluster on Amazon Web Services (AWS) in the Malaysia (ap-southeast-5) and Thailand (ap-southeast-7) regions.

For more information, see Supported Amazon Web Services (AWS) regions.

In OpenShift Container Platform 4.19, the installation program uses the Cluster API instead of Terraform to provision clusters during installer-provisioned infrastructure installations on Microsoft Azure Stack Hub.

Additional Microsoft Azure instance types for machine types based on 64-bit x86 architecture have been tested with OpenShift Container Platform 4.19.

For the Dxv6 machine series, the following instance types have been tested:

For the Lsv4 and Lasv4 machine series, the following instance types have been tested:

For the ND and NV machine series, the following instance types have been tested:

For more information, see Tested instance types for Azure and Azure documentation (Microsoft documentation).

On 30 September 2025, the default outbound access connectivity for all new virtual machines (VMs) in Microsoft Azure will be retired. To enhance security, Azure is moving towards a secure-by-default model where default outbound access to the internet will be turned off. However, configuration changes to OpenShift Container Platform are not required. By default, the installation program creates an outbound rule for the load balancer.

For more information, see Azure Updates (Microsoft documentation), Azure’s outbound connectivity methods (Microsoft documentation), and Preparing to install a cluster on Azure.

With this release, you can use additional Confidential Computing platforms on GCP. The new supported platforms, which can be enabled in the install-config.yaml file prior to installation, or configured after installation by using machine sets and control plane machine sets, are as follows:

For more information, see Installation configuration parameters for Google Cloud Platform, Configuring Confidential VM by using machine sets (control plane), and Configuring Confidential VM by using machine sets (compute).

With this release, you can enable a user-provisioned domain name server (DNS) instead of the default cluster-provisioned DNS solution. For example, your organization’s security policies might not allow the use of public DNS services such as Google Cloud DNS. You can manage your DNS only for the IP addresses of the API and Ingress servers. If you use this feature, you must provide your own DNS solution that includes records for api.<cluster_name>.<base_domain>. and *.apps.<cluster_name>.<base_domain>.. Enabling a user-provisioned DNS is available as a Technology Preview feature.

For more information, see Enabling user-managed DNS.

With this release, you can install a cluster on VMware vSphere with multiple storage disks as a Technology Preview feature. You can assign these additional disks to special functions within the cluster, such as etcd storage.

For more information, see Optional vSphere configuration parameters.

With this release, you can enable boot diagnostics collection when you install a cluster on Microsoft Azure. Boot diagnostics is a debugging feature for Azure virtual machines (VMs) to identify VM boot failures. You can set the bootDiagnostics parameter in the install-config.yaml file for compute machines, for control plane machines, or for all machines.

For more information, see Additional Azure configuration parameters.

OpenShift Container Platform 4.19 uses Kubernetes 1.32, which removed several deprecated APIs.

A cluster administrator must provide manual acknowledgment before the cluster can be updated from OpenShift Container Platform 4.18 to 4.19. This is to help prevent issues after updating to OpenShift Container Platform 4.19, where APIs that have been removed are still in use by workloads, tools, or other components running on or interacting with the cluster. Administrators must evaluate their cluster for any APIs in use that will be removed and migrate the affected components to use the appropriate new API version. After this is done, the administrator can provide the administrator acknowledgment.

All OpenShift Container Platform 4.18 clusters require this administrator acknowledgment before they can be updated to OpenShift Container Platform 4.19.

For more information, see Preparing to update to OpenShift Container Platform 4.19.

With this release, you can map OpenShift Container Platform failure domains to VMware vSphere host groups. This enables you to make use of the high availability offered by a vSphere stretched cluster configuration. This feature is available as a Technology Preview in OpenShift Container Platform 4.19.

For information on configuring host groups at installation, see VMware vSphere host group enablement.

For information on configuring host groups for existing clusters, see Specifying multiple host groups for your cluster on vSphere.

With this release, you can now use the Agent-based Installer to install a cluster on Nutanix. Installing a cluster on Nutanix with the Agent-based Installer is enabled by setting the platform parameter to nutanix in the install-config.yaml file.

For more information, see Required configuration parameters in the Agent-based Installer documentation.

Red Hat Enterprise Linux CoreOS (RHCOS) image layering is now called image mode for OpenShift. As a part of this change, on-cluster layering is now called on-cluster image mode and out-of-cluster layering is now out-of-cluster image mode.

The updated boot images feature is now called boot image management.

Image mode for OpenShift, formerly called on-cluster layering, is now Generally Available (GA). The following changes have been introduced with the promotion to GA:

The boot image management feature, previously called updated boot images, is now the default behavior in Google Cloud Platform (GCP) and Amazon Web Services (AWS) clusters. As such, after updating to OpenShift Container Platform 4.19, the boot images in your cluster are automatically updated to version 4.19. With subsequent updates, the Machine Config Operator (MCO) again updates the boot images in your cluster. A boot images is associated with a machine set and is used when scaling new nodes. Any new nodes you create after updating are based on the new version. Current nodes are not affected by this feature.

Before upgrading to 4.19, you must opt-out of this default behavior or acknowledge this change before proceeding. For more information, see Disabling boot image management.

The Machine Config Server (MCS) CA bundle created by the installation program is now stored in the machine-config-server-ca config map in the openshift-machine-config-operator namespace. The bundle was previously stored in the root-ca configmap in the kube-system namespace. The root-ca configmap is no longer used in a cluster that cluster that is updated to OpenShift Container Platform 4.19. This change was made to make it clear that this CA bundle is managed by the Machine Config Operator (MCO).

The MCS signing key is stored in the machine-config-server-ca secret in the openshift-machine-config-operator namespace.

The MCS CA and MCS cert are valid for 10 years and are automatically rotated by the MCO at approximately 8 years. Upon update to OpenShift Container Platform 4.19, the CA signing key is not present. As a result, the CA bundle is immediately considered expired when the MCO certificate controller comes up. This expiration causes an immediate certificate rotation, even if the cluster is not 10 years old. After that point, the next rotation takes place at the standard 8 year period.

For more information about the MCO certificates, see Machine Config Operator certificates.

With this release, you can migrate some resources between the Cluster API and the Machine API on Amazon Web Services (AWS) as a Technology Preview feature. For more information, see Migrating Machine API resources to Cluster API resources.

To support this capability, the OpenShift Container Platform Cluster API documentation now includes additional configuration details for AWS clusters.

With this release, you can customize the prefix of machine names for machines created by the control plane machine set. This feature is enabled by modifying the spec.machineNamePrefix parameter of the ControlPlaneMachineSet custom resource.

For more information, see Adding a custom prefix to control plane machine names.

With this release, you can deploy machines that use Capacity Reservations, including On-Demand Capacity Reservations and Capacity Blocks for ML, on Amazon Web Services clusters.

You can configure these features with compute and control plane machine sets.

With this release, you can add up to 29 disks to the virtual machine (VM) controller for your vSphere cluster as a Technology Preview feature. This capability is available for compute and control plane machine sets.

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

This release introduces a major update to the Prometheus component, transitioning from v2 to v3. The monitoring stack and other core components include all of the necessary adjustments to ensure a smooth upgrade. However, some user-managed configurations might require modifications. The key changes include the following items:

For more information about the changes between Prometheus v2 and v3, see Prometheus 3.0 migration guide.

OpenShift Container Platform 4.13 introduced the ability to set a metrics collection profile for default platform monitoring to collect either the default amount of metrics data or a minimal amount of metrics data. In OpenShift Container Platform 4.19, metrics collection profiles are now generally available.

For more information, see About metrics collection profiles and Choosing a metrics collection profile.

With this release, external Alertmanager instances now use the cluster-wide HTTP proxy settings for communication. The Cluster Monitoring Operator (CMO) reads the cluster-wide proxy settings and configures the appropriate proxy URL for the Alertmanager endpoints.

With this release, the strict validation introduced in OpenShift Container Platform 4.18 is improved. Error messages now clearly identify the affected field, and validation is case-sensitive to ensure more accurate and consistent configuration.

For more information, see (OCPBUGS-42671) and (OCPBUGS-54516).

With this release, OpenShift Container Platform routes can be configured with third-party certificate management solutions, utilizing the .spec.tls.externalCertificate field in the route API. This allows you to reference externally managed TLS certificates through secrets, streamlining the process by eliminating manual certificate management. By using externally managed certificates, you reduce errors, ensure a smoother certificate update process, and enable the OpenShift router to promptly serve renewed certificates. For more information, see Creating a route with externally managed certificate.

With this release, support for managing ingress cluster traffic using Gateway API resources is Generally Available. Gateway API provides a robust networking solution within the transport layer, L4, and the application layer, L7, for OpenShift Container Platform clusters using a standardized open source ecosystem.

For more information, see Gateway API with OpenShift Container Platform networking.

With this release, OpenShift Container Platform manages the lifecycle of Gateway API CRDs. This means that the Ingress Operator handles the required versioning and management of resources. Any Gateway API resources created in a previous OpenShift Container Platform version must be re-created and redeployed so that it conforms to the specifications required by the Ingress Operator.

For more information, see Preparing for Gateway API management succession by the Ingress Operator.

OpenShift Container Platform 4.19 updates Red Hat OpenShift Service Mesh to version 3.0.2, and Gateway API to version 1.2.1. See the Service Mesh 3.0.0 release notes and the Gateway API 1.2.1 changelog for more information.

You can enable the Open vSwitch (OVS) balance-slb mode on infrastructure where your cluster runs so that two or more physical interfaces can share their network traffic. For more information, see Enabling OVS balance-slb mode for your cluster.

With this release, you can now allocate load balancers to customize deployments when installing an OpenShift Container Platform cluster on AWS. This feature ensures optimal traffic distribution, high application availability, uninterrupted service, and network segmentation.

For more information, see Installation configuration parameters on AWS and Allocating load balancers to specific subnets.

With this release, you can use a dual-port network interface controller (NIC) to improve redundancy for Precision Time Protocol (PTP) ordinary clocks. Available as a Technology Preview, in a dual-port NIC configuration for an ordinary clock, if one port fails, the standby port takes over, maintaining PTP timing synchronization.

For more information, see Using dual-port NICs to improve redundancy for PTP ordinary clocks.

You can now enable the featureGates.resourceInjectorMatchCondition feature in the SriovOperatorConfig object to limit the scope of the Network Resources Injector webhook. If this feature is enabled, the webhook applies only to pods with the secondary network annotation k8s.v1.cni.cncf.io/networks.

If this feature is disabled, the webhook’s failurePolicy is set to Ignore by default. This configuration can cause pods requesting SR-IOV networks to be deployed without the required resource injection if the webhook is unavailable. If this feature is enabled and the webhook is unavailable, pods without the annotation are still deployed, preventing unnecessary disruptions to other workloads.

For more information, see About the Network Resources Injector

With this release, OpenShift Container Platform introduces the Data Processing Unit (DPU) Operator and using the Operator to manage DPU devices. The DPU Operator manages components on compute nodes that have configured DPUs, such as enabling the offloading of data networking, storage, and security workloads. Enabling DPU device management leads to improved cluster performance, reduced latency, and enhanced security, that overall contribute to a more efficient cluster infrastructure. For more information, see About DPU and the DPU Operator.

Administrators can now use the ClusterUserDefinedNetwork custom resource to deploy secondary networks on a Localnet topology. This feature allows pods and virtual machines connected to the localnet network to egress to the physical network. For more information, see Creating a ClusterUserDefinedNetwork CR for a Localnet topology.

You can enable port isolation for a Linux bridge network attachment definition (NAD) so that virtual machines (VMs) or pods that run on the same virtual LAN (VLAN) can operate in isolation from one another. For more information, see Enabling port isolation for a Linux bridge NAD.

To improve the performance of Whereabouts, especially if nodes in your cluster run a high amount of pods, you can now enable the Fast IP Address Management (IPAM) feature. The Fast IPAM feature uses nodeslicepools, which are managed by the Whereabouts Controller, to optimize IP address allocation for nodes. For more information, see Fast IPAM configuration for the Whereabouts IPAM CNI plugin.

With this release, OpenShift Container Platform introduces unnumbered BGP peering. Available as a Technology Preview feature, you can use the spec.interface field of the BGP peer custom resource to configure unnumbered BGP peering.

In a disconnected environment where the external DNS server cannot be reached, you can resolve Kubernetes NMState Operator health probe issues by specifying a custom DNS host name in the NMState custom resource definition (CRD). For more information, see Creating a custom DNS host name to resolve DNS connectivity issues.

With this release, the PTP events REST API v1 and events consumer application sidecar support are removed.

You must use the O-RAN compliant PTP events REST API v2 instead.

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

You can now deploy the SR-IOV Network Operator on a cluster that runs on ARM architecture. (OCPBUGS-56271)

If you enabled the RouteExternalCertificate feature gate for your cluster, you can now re-add a previously deleted secret. (OCPBUGS-33958)

Starting with OpenShift Container Platform 4.19, the oc-mirror plugin v2 supports mirroring and verifying cosign tag-based signatures for container images.

The following base images for Operator projects are updated for compatibility with OpenShift Container Platform 4.19. The runtime functionality and configuration APIs for these base images are supported for bug fixes and for addressing CVEs.

For more information, see Updating the base image for existing Ansible- or Helm-based Operator projects for OpenShift Container Platform 4.19 and later (Red Hat Knowledgebase).

In OpenShift Container Platform 4.19, you can deploy non-OpenShift Container Platform nodes by using bare metal as a service (BMaaS). BMaaS nodes can run workloads that might not be suitable for containerization or virtualization. For example, workloads such as applications that require direct hardware access, conduct high-performance computing tasks or are legacy applications and operate independently of the cluster are suitable for deployment by using BMaaS.

For more information, see Using bare metal as a service.

RHCOS uses Red Hat Enterprise Linux (RHEL) 9.6 packages in OpenShift Container Platform 4.19. These packages ensure that your OpenShift Container Platform instances receive the latest fixes, features, enhancements, hardware support, and driver updates.

With this update, you can specify larger kernel page sizes to improve performance for memory-intensive, high-performance workloads on ARM infrastructure nodes with the realtime kernel disabled. For more information, see Configuring kernel page sizes.

This release includes the following usability and functional updates to the cluster-compare plugin:

For a complete list of available template functions, see Reference template functions

With this update, you can now tune nodes in hosted control planes for low latency by applying a performance profile. For more information, see Creating a performance profile for hosted control planes.

With this release, the control plane supports TLS 1.3. You can now use the Modern TLS security profile for the control plane.

For more information, see Configuring the TLS security profile for the control plane.

With this release, you can use the External Secrets Operator for Red Hat OpenShift to authenticate with the external secrets store, retrieve secrets, and inject the retrieved secrets into a native Kubernetes secret. The External Secrets Operator for Red Hat OpenShift is available as a Technology Preview.

For more information, see External Secrets Operator for Red Hat OpenShift overview

With this release, the secrets store providers support by using the Secrets Store CSI driver in disconnected clusters.

For more information, see Support for disconnected environments.

Cross-subscription support allows you to have an OpenShift Container Platform cluster in one Azure subscription and mount your Azure file share in another Azure subscription using the Azure File Container Storage Interface (CSI) driver. The subscriptions must be in the same tenant.

This feature is generally available in OpenShift Container Platform 4.19.

For more information, see AWS EFS CSI cross account support.

Volume Attributes Classes provide a way for administrators to describe "classes" of storage they offer. Different classes might correspond to different quality-of-service levels.

Volume Attributes Classes in OpenShift Container Platform 4.19 is available only with AWS Elastic Block Storage (EBS) and Google Cloud Platform (GCP) persistent disk (PD) Container Storage Interface (CSI).

You can apply a Volume Attributes Classes to a persistent volume claim (PVC). If a new Volume Attributes Class becomes available in the cluster, you can update the PVC with the new Volume Attributes Classes if needed.

Volume Attributes Classes have parameters that describe volumes belonging to them. If a parameter is omitted, the default is used at volume provisioning. If a user applies the PVC with a different Volume Attributes Class with omitted parameters, the default value of the parameters might be used depending on the CSI driver implementation. For more information, see the related CSI driver documentation.

Volume Attributes Classes is available in OpenShift Container Platform 4.19 with Technology Preview status.

For more information, see Volume Attributes Classes.

OpenShift Container Platform 4.19 introduces a new command to view persistent volume claim usage. This feature has Technology Preview status.

For more information, see Viewing PVC usage statistics.

Previously, you might expand a persistent volume claim (PVC) to a size that is not supported by the underlying storage provider. In this case, the expansion controller typically tries forever to expand the volume and keeps failing.

This new feature allows you to recover and provide another resize value for the PVC. Resizing recovery is supported as generally available in OpenShift Container Platform 4.19.

For more information about resizing volumes, see Expanding persistent volumes.

For more information about recovering when resizing volumes, see Recovering from failure when expanding volumes.

Previously, VMware vSphere persistent volumes that were migrated from in-tree to Container Storage Interface (CSI) could not be resized. With OpenShift Container Platform 4.19, resizing migrated volumes is supported. This feature is generally available.

For more information about resizing volumes, see Expanding persistent volumes.

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 features was introduced in OpenShift Container Platform 4.17 with Technology Preview status. This feature is now supported as generally available in OpenShift Container Platform 4.19.

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

For VMware vSphere version 7, OpenShift Container Platform restricts the maximum number of volumes per node to 59.

However, with OpenShift Container Platform 4.19 for vSphere version 8 or later, you can increase the allowable number of volumes per node to a maximum of 255. Otherwise, the default value remains at 59.

This feature has Technology Preview status.

For more information, see Increasing maximum volumes per node for vSphere.

If you are running out of space in your current datastore, or want to move to a more performant datastore, you can migrate VMware vSphere Cloud Native Storage (CNS) volumes between datastores. This applies to both attached and detached volumes.

OpenShift Container Platform now fully supports migration of CNS volume using the vCenter UI. Migrated volumes should work as expected and should not result in non-functional persistent volumes. CNS volumes can also be migrated while in use by pods.

This feature was introduced as a Development Preview in OpenShift Container Platform 4.17, but is now fully supported in 4.19.

Migrating CNS volumes between datastores requires VMware vSphere 8.0.2 or later or vSphere 7.0 Update 3o or later.

For more information, see Migrating CNS volumes between datastores for vSphere.

By default, a Filestore instance grants root level read/write access to all clients that share the same Google Cloud project and virtual private cloud (VPC) network. Network File System (NFS) export options can limit this access to certain IP ranges and specific user/group IDs for the Filestore instance. When creating a storage class, you can set these options using the nfs-export-options-on-create parameter.

NFS export options is supported as generally available in OpenShift Container Platform 4.19.

For more information, see NFS export options.

The web console now uses Patternfly 6. Support for Patternfly 4 in the web console is no longer available.

This release also introduces the following updates to the web console. You can now do the following actions:

The oc adm pod-network command for working with OpenShift SDN multitenant mode has been removed from the oc adm --help output. If the oc adm pod-network command is used, an error message is displayed to tell users that it has been deprecated.

With this release, support for the useModal hook in dynamic plugins are deprecated.

Starting with this release, use the useOverlay API hook to launch modals

cgroup v1, which was deprecated in OpenShift Container Platform 4.16, is no longer supported and has been removed from OpenShift Container Platform. If your cluster is using cgroup v1, you must configure cgroup v2 before you can upgrade to OpenShift Container Platform 4.19. All workloads must now be compatible with cgroup v2.

For information on configuring cgroup v2 in your cluster, see Configuring Linux cgroup in the OpenShift Container Platform version 4.18 documentation.

For more information on cgroup v2, see About Linux cgroup version 2 and Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads (Red Hat blog).

With this release, support for the installation of packaged-based RHEL worker nodes is removed.

RHCOS image layering replaces this feature and supports installing additional packages on the base operating system of your worker nodes.

For information on how to identify and remove RHEL nodes in your cluster, see Preparing to update from OpenShift Container Platform 4.18 to a newer version. For more information on image layering, see RHCOS image layering.

Kubernetes 1.32 removed the following deprecated APIs, so you must migrate manifests and API clients to use the appropriate API version. For more information about migrating removed APIs, see the Kubernetes documentation.

With this release, the Red Hat-supported version of the Operator SDK CLI tool, including the related scaffolding and testing tools for Operator projects, is no longer released with OpenShift Container Platform.

Red Hat will provide bug fixes and support for versions of the Operator SDK that were released with earlier versions of OpenShift Container Platform according to the Product Life Cycles for OpenShift Container Platform 4 (Red Hat Customer Portal).

Operator authors with existing Operator projects can use the version of the Operator SDK CLI tool released with OpenShift Container Platform 4.18 to maintain their projects and create Operator releases that target newer versions of OpenShift Container Platform. For more information, see Updating the base image for existing Ansible- or Helm-based Operator projects for OpenShift Container Platform 4.19 and later (Red Hat Knowledgebase).

For more information about the unsupported, community-maintained, version of the Operator SDK, see Operator SDK (Operator Framework).

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

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

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

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