Chapter 1. OpenShift Container Platform 4.18 release notes

With this release, you can use the Cloud Credential Operator (CCO) utility (ccoctl) to rotate the OpenID Connect (OIDC) bound service account signer key for clusters installed on the following cloud providers:

With this release, you can now hibernate your OpenShift Container Platform cluster for up to 90 days and expect the cluster to recover successfully. Before this release, you could only hibernate for up to 30 days.

For more information, see Hibernating an OpenShift Container Platform cluster.

The etcd disaster recovery documentation was updated and simplified for quicker recovery of the cluster, both in a normal disaster recovery situation and in cases where a full cluster restoration from a previous backup is not necessary.

Two scripts, quorum-restore.sh and cluster-restore.sh, are introduced to complete many of the steps in the recovery procedure.

In addition, a procedure was added to more quickly recover the cluster when at least one good node exists. If any of the surviving nodes meets specific criteria, you can use it to run the recovery.

For more information, see About disaster recovery.

With this release, you can shut down and restart single-node OpenShift clusters up to 1 year after cluster installation. If certificates expired while the cluster was shut down, you must approve certificate signing requests (CSRs) upon restarting the cluster.

Before this update, you could shut down and restart single-node OpenShift clusters for only 120 days after cluster installation.

For more information, see Shutting down the cluster gracefully.

Operator Lifecycle Manager (OLM) has been included with OpenShift Container Platform 4 since its initial release and has helped enable and grow a substantial ecosystem of solutions and advanced workloads running as Operators.

OpenShift Container Platform 4.18 introduces OLM v1, the next-generation Operator Lifecycle Manager, as a General Availability (GA) feature, designed to improve how you manage Operators on OpenShift Container Platform.

With OLM v1 now generally available, starting in OpenShift Container Platform 4.18, the existing version of OLM that has been included since the launch of OpenShift Container Platform 4 is now known as OLM (Classic).

Previously available as a Technology Preview feature only, the updated framework in OLM v1 evolves many of the concepts that have been part of OLM (Classic) by simplifying Operator management, enhancing security, and boosting reliability.

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.

To support cluster administrators that prioritize high security by running their clusters in internet-disconnected environments, especially for mission-critical production workloads, OLM v1 supports these disconnected environments, starting in OpenShift Container Platform 4.18.

After using the oc-mirror plugin for the OpenShift CLI (oc) to mirror the images required for your cluster to a mirror registry in your fully or partially disconnected environments, OLM v1 can function properly in these environments by utilizing the sets of resources generated by either oc-mirror plugin v1 or v2.

For more information, see Disconnected environment support in OLM v1.

With this release, you can perform the following actions to control the selection of catalog content when you install or update a cluster extension:

For more information, see Catalog content resolution.

With this release, Operator Controller and catalogd can now run in proxied environments and include basic support for trusted CA certificates.

Before cluster administrators can update their OpenShift Container Platform cluster to its next minor version, they must ensure that all installed Operators are updated to a bundle version that is compatible with the next minor version (4.y+1) of a cluster.

Starting in OpenShift Container Platform 4.18, OLM v1 supports the olm.maxOpenShiftVersion annotation in the cluster service version (CSV) of an Operator, similar to the behavior in OLM (Classic), to prevent administrators from updating the cluster before updating the installed Operator to a compatible version.

For more information, see Compatibility with OpenShift Container Platform versions.

After a cluster extension has been installed and is being managed by Operator Lifecycle Manager (OLM) v1, the extension can often provide CustomResourceDefinition objects (CRDs) that expose new API resources on the cluster. Cluster administrators typically have full management access to these resources by default, whereas non-cluster administrator users, or regular users, might lack sufficient permissions.

OLM v1 does not automatically configure or manage role-based access control (RBAC) for regular users to interact with the APIs provided by installed extensions. Cluster administrators must define the required RBAC policy to create, view, or edit these custom resources (CRs) for such users.

For more information, see User access to extension resources.

Starting in OpenShift Container Platform 4.18, OLM v1 support for handling runtime validation of sigstore signatures for container images is available as a Technology Preview (TP) feature.

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

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.

SiteConfig v1 is deprecated starting with OpenShift Container Platform 4.18. Equivalent and improved functionality is now available through the SiteConfig Operator using the ClusterInstance custom resource. For more information, see the Red Hat Knowledge Base solution Procedure to transition from SiteConfig CRs to the ClusterInstance API.

For more information about the SiteConfig Operator, see SiteConfig.

In this release, the Insights Operator introduces the workload data collection Insights Runtime Extractor feature to help Red Hat better understand the workload of your containers. Available as a Technology Preview, the Insights Runtime Extractor feature gathers runtime workload data and sends it to Red Hat. Red Hat uses the collected runtime workload data to gain insights that can help you make investment decisions that will drive and optimize how you use your OpenShift Container Platform containers. For more information, see Enabling features using feature gates.

In this release, enhancements have been made to the Rapid Recommendations mechanism for remotely configuring the rules that determine the data that the Insights Operator collects.

The Rapid Recommendations feature is version-independent, and 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 get configured through an attribute named conditionalGathererEndpoint in the pod.yml configuration file.

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:

The installation program now uses a newer version of the Cluster API Provider IBM Cloud provider that includes Transit Gateway fixes. Because of the cost of Transit Gateways in IBM Cloud, you can now use the OpenShift Container Platform to create a Transit Gateway when creating an OpenShift Container Platform cluster. For more information, see (OCPBUGS-37588) and (OCPBUGS-41938).

With this release, you can configure the IPv4 join subnet that is used internally by ovn-kubernetes when installing a cluster. You can set the internalJoinSubnet parameter in the install-config.yaml file and deploy the cluster into an existing Virtual Private Cloud (VPC).

For more information, see Network configuration parameters.

When updating your cluster, the oc adm upgrade command returns a list of the next available versions. As long as you are using 4.18 oc client binary, you can use the oc adm upgrade recommend command to narrow down your suggestions and recommend a new target release before you launch your update. This feature is available for OpenShift Container Platform version 4.16 and newer clusters that are connected to an update service.

For more information, see Updating a cluster by using the CLI

With this release, you can install OpenShift Container Platform on Nutanix Cloud Clusters (NC2) on AWS or NC2 on Azure.

For more information, see Infrastructure requirements.

With this release, you can deploy a cluster on GCP using the C4 and C4A machine series for compute or control plane machines. The supported disk type of these machines is hyperdisk-balanced. If you use an instance type that requires Hyperdisk storage, all of the nodes in your cluster must support Hyperdisk storage, and you must change the default storage class to use Hyperdisk storage.

For more information about configuring machine types, see Installation configuration parameters for GCP, C4 machine series (Compute Engine docs), and C4A machine series (Compute Engine docs).

With this release, you can provide your own private hosted zone when installing a cluster on GCP into a shared VPC. If you do, the requirements for the bring your own (BYO) zone are that the zone must use a DNS name such as <cluster_name>.<base_domain>. and that you bind the zone to the VPC network of the cluster.

For more information, see Prerequisites for installing a cluster on GCP into a shared VPC and Prerequisites for installing a cluster into a shared VPC on GCP using Deployment Manager templates.

With this release, you can install a cluster on Nutanix by using the named, preloaded RHCOS image object from the private cloud or the public cloud. Rather than creating and uploading a RHCOS image object for each OpenShift Container Platform cluster, you can use the preloadedOSImageName parameter in the install-config.yaml file.

For more information, see Additional Nutanix configuration parameters.

You can now deploy single-stack IPv6 clusters on RHOSP.

You must configure RHOSP prior to deploying your OpenShift Container Platform cluster. For more information, see Configuring a cluster with single-stack IPv6 networking.

With this release, you can install a Nutanix cluster with more than one subnet for the Prism Element into which you are deploying an OpenShift Container Platform cluster.

For more information, see Configuring failure domains and Additional Nutanix configuration parameters.

For an existing Nutanix cluster, you can add multiple subnets by using compute or control plane machine sets.

With this release, you can install a VMware vSphere cluster with multiple network interface controllers (NICs) for a node.

For more information, see Configuring multiple NICs.

For an existing vSphere cluster, you can add multiple subnets by using compute machine sets.

With this release, if you are using the Agent-based Installer, you can now configure your cluster to be installed with either 4 or 5 nodes in the control plane. This feature is enabled by setting the controlPlane.replicas parameter to either 4 or 5 in the install-config.yaml file.

For more information, see Optional configuration parameters for the Agent-based Installer.

With this release, the Agent-based Installer supports creating a minimal ISO image on all supported platforms. Previously, minimal ISO images were supported only on the external platform.

This feature is enabled using the minimalISO parameter in the agent-config.yaml file.

For more information, see Optional configuration parameters for the Agent-based Installer.

With this release, the Agent-based Installer supports creating assets that can be used to boot an OpenShift Container Platform cluster from an iSCSI target.

For more information, see Preparing installation assets for iSCSI booting.

Updated boot images has been promoted to GA for Amazon Web Services (AWS) clusters. For more information, see Updated boot images.

The image config nodes custom resource, that you can use to monitor the progress of machine configuration updates to nodes, now presents more information on the update. The output of the oc get machineconfignodes command now reports on the following and other conditions. You can use these statuses to follow the update, or troubleshoot the node if it experiences an error during the update:

There are several important changes to the on-cluster layering feature:

For more information about on-cluster layering, see Using on-cluster layering to apply a custom layered image.

With this update, the checkbox for enabling cluster monitoring is now checked by default when installing the OpenShift Lightspeed Operator. (OCPBUGS-42381)

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

With this update, you can configure the intervals between consecutive scrapes and between rule evaluations for Prometheus for user workload monitoring.

This update introduces early validation for changes to monitoring configurations in cluster-monitoring-config and user-workload-monitoring-config config maps to provide shorter feedback loops and enhance user experience.

With this update, Alertmanager uses the proxy environment variables. Therefore, if you configured an HTTP cluster-wide proxy, you can enable proxying by setting the proxy_from_environment parameter to true in your alert receivers or at the global config level in Alertmanager.

With this update, you can create user workload alerting and recording rules that query multiple projects at the same time.

You can now correlate observability metrics for clusters that run on Red Hat OpenStack Services on OpenShift (RHOSO). By collecting metrics from both environments, you can monitor and troubleshoot issues across the infrastructure and application layers.

For more information, see Monitoring clusters that run on RHOSO.

With this release, you can configure the holdover behavior in a grandmaster (T-GM) clock with Global Navigation Satellite System (GNSS) as the source. Holdover allows the T-GM clock to maintain synchronization performance when the GNSS source is unavailable. During this period, the T-GM clock relies on its internal oscillator and holdover parameters to reduce timing disruptions.

You can define the holdover behavior by configuring the following holdover parameters in the PTPConfig custom resource (CR):

For more information, see Holdover in a grandmaster clock with GNSS as the source.

With this release, you can configure a multi-network policy for the following network types:

For more information, see Configuring multi-network policy

The terminology for the ip_whitelist and ip_blacklist annotations have been updated to ip_allowlist and ip_denylist, respectively. Currently, OpenShift Container Platform still supports the ip_whitelist and ip_blacklist annotations. However, these annotations are planned for removal in a future release.

OVN-Kubernetes network traffic can be viewed with OVS sampling via the CLI for the following network APIs:

Checking OVN-Kubernetes network traffic with OVS sampling using the CLI is intended to help with packet tracing. It can also be used while the Network Observability Operator is installed.

For more information, see Checking OVN-Kubernetes network traffic with OVS sampling using the CLI.

With OpenShift Container Platform 4.18, user-defined network segmentation is generally available. User-defined networks (UDN) introduce enhanced network segmentation capabilities by allowing administrators to define custom network topologies using namespace-scoped UserDefinedNetwork and cluster-scoped ClusterUserDefinedNetwork custom resources.

With UDNs, administrators can create tailored network topologies with enhanced isolation, IP address management for workloads, and advanced networking features. Supporting both Layer 2 and Layer 3 topology types, user-defined network segmentation enables a wide range of network architectures and topologies, enhancing network flexibility, security, and performance. For more information on supported features, see UDN support matrix.

Use cases of UDN include providing virtual machines (VMs) with a lifetime duration for static IP addresses assignment as well as a Layer 2 primary pod network so that users can live migrate VMs between nodes. These features are all fully equipped in OpenShift Virtualization. Users can use UDNs to create a stronger, native multi-tenant environment, allowing you to secure your overlay Kubernetes network, which is otherwise open by default. For more information, see About user-defined networks.

You can reduce your memory footprint by using the dynamic configuration manager on Ingress Controllers. The dynamic configuration manager propagates endpoint changes through a dynamic API. This process enables the underlying routers to adapt to changes (scale ups and scale downs) without reloads.

To use the dynamic configuration manager, enable the TechPreviewNoUpgrade feature set by running the following command:

$ oc patch featuregates cluster -p '{"spec": {"featureSet": "TechPreviewNoUpgrade"}}' --type=merge

With this release, you can view network information for ingress flows to OpenShift Container Platform services in the following environments:

For more information, see OpenShift Container Platform network flow matrix.

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.

With this release, you can configure a Remote Direct Memory Access (RDMA) Container Network Interface (CNI) on Single Root I/O Virtualization (SR-IOV) to enable high-performance, low-latency communication between containers. When you combine RDMA with SR-IOV, you provide a mechanism to expose hardware counters of Mellanox Ethernet devices to be used inside Data Plane Development Kit (DPDK) applications.

With this release, you can configure the Single Root I/O Virtualization (SR-IOV) Network Operator when the system has secure boot enabled. The SR-IOV Operator is configured after you first manually configure the firmware for Mellanox devices. With secure boot enabled, the resilience of your system is enhanced, and a crucial layer of defense for the overall security of your computer is provided.

For more information, see Configuring the SR-IOV Network Operator on Mellanox cards when Secure Boot is enabled.

With this release, you can now specify pre-created floating IP addresses in the Ingress Controller for your clusters running on RHOSP.

For more information, see Specifying a floating IP address in the Ingress Controller.

The SR-IOV Network Operator now supports Intel NetSec Accelerator Cards and Marvell Octeon 10 DPUs. (OCPBUGS-43451)

The OVN-Kubernetes plugin can now use a Linux bridge interface as the Open vSwitch (OVS) default port connection. This means that a network interface controller, such as SmartNIC, can now bridge the underlying network with a host. (OCPBUGS-39226)

When you start the limited live migration method and an issue exists with network overlap, the Cluster Network Operator (CNO) can now expose network overlap metrics for the issue. This is possible because the openshift_network_operator_live_migration_blocked metric now includes the new NetworkOverlap label. (OCPBUGS-39096)

Previously, the NetworkAttachmentDefinition CR was immutable. With this release, you can edit an existing NetworkAttachmentDefinition CR. Support for editing makes it easier to accommodate changes in the underlying network infrastructure, such as adjusting the MTU of a network interface.

You must ensure that the configurations of each NetworkAttachmentDefinition CR that reference the same network name and type: ovn-k8s-cni-overlay are in sync. Only when these values are in sync is the network attachment update successful. If the configurations are not in sync, the behavior is undefined because there is no guarantee about which NetworkAttachmentDefinition CR OpenShift Container Platform uses for the configuration.

You still must restart any workloads that use the network attachment definition for the network changes to take effect for those pods.

crun is now the default container runtime for new containers created in OpenShift Container Platform. The runC runtime is still supported and you can change the default runtime to runC, if needed. For more information on crun, see About the container engine and container runtime. For information on changing the default to runC, see Creating a ContainerRuntimeConfig CR to edit CRI-O parameters.

Updating from OpenShift Container Platform 4.17.z to OpenShift Container Platform 4.18 does not change your container runtime.

Available as a Technology Preview, you can use the sigstore project with OpenShift Container Platform to improve supply chain security. You can create signature policies at the cluster-wide level or for a specific namespace. For more information, see Manage secure signatures with sigstore.

Enhancements have been added to the process for adding worker nodes to an on-premise cluster that was introduced in OpenShift Container Platform 4.17. With this release, you can now generate Preboot Execution Environment (PXE) assets instead of an ISO image file, and you can configure reports to be generated regardless of whether the node creation process fails or not.

The Node Tuning Operator can now properly select kernel arguments and management options for Intel and AMD CPUs. (OCPBUGS-43664)

The default container runtime that is set by the cluster Node Tuning Operator is always inherited from the cluster, and is not hard-coded by the Operator. Starting with this release, the default value is crun. (OCPBUGS-45450)

oc-mirror plugin v2 is now generally available. To use it, add the --v2 flag when running oc-mirror commands. The previous version (oc-mirror plugin v1), which runs when the --v2 flag is not set, is now deprecated. It is recommended to transition to oc-mirror plugin v2 for continued support and improvements.

For more information, see Mirroring images for a disconnected installation by using the oc-mirror plugin v2.

oc-mirror plugin v2 now supports mirroring helm charts. Also, oc-mirror plugin v2 can now be used in environments where HTTP/S proxy is enabled, ensuring broader compatibility with enterprise setups.

oc-mirror plugin v2 introduces v1 retro-compatible filtering of Operator catalogs and generates filtered catalogs. This feature allows cluster administrators to view only the Operators that have been mirrored, rather than the complete list from the origin catalog.

With the release of Operator Lifecycle Manager (OLM) v1 as a General Availability (GA) feature, starting in OpenShift Container Platform 4.18, the existing version of OLM that has been included since the launch of OpenShift Container Platform 4 is now known as OLM (Classic).

For more information on the GA release of OLM v1, see the Extensions (OLM v1) release note sections. For full documentation focused on OLM v1, see the stand-alone Extensions guide.

For full documentation focused on OLM (Classic), continue referring to the Operators guide.

This release introduces the ability to manage machines by using the upstream Cluster API, integrated into OpenShift Container Platform, as a Technology Preview for Microsoft Azure clusters. This capability is in addition or an alternative to managing machines with the Machine API. For more information, see About the Cluster API.

OpenShift Container Platform cluster installations on Oracle® Cloud Infrastructure (OCI) are now supported for bare-metal machines. You can install bare-metal clusters on OCI by using either the Assisted Installer or the Agent-based Installer. To install a bare-metal cluster on OCI, choose one of the following installation options:

With this release, you can migrate the control plane in your cluster from x86 to arm64 architecture on Amazon Web Services (AWS). For more information, see Migrating the x86 control plane to arm64 architecture on Amazon Web Services.

This feature introduces a new field, imageStreamImportMode, in the image.config.openshift.io/cluster resource. The imageStreamImportMode field controls the import mode behavior of image streams. You can set the imageStreamImportMode field to either of the following values:

For more information, see Image controller configuration parameters.

You must enable the TechPreviewNoUpgrade feature set in the FeatureGate custom resource (CR) to enable the imageStreamImportMode feature. For more information, see Understanding feature gates.

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

The cluster-compare plugin is an OpenShift CLI (oc) plugin that compares a cluster configuration with a target configuration. The plugin reports configuration differences while suppressing expected variations by using configurable validation rules and templates.

For example, the plugin can highlight unexpected differences, such as mismatched field values, missing resources, or version discrepancies, while ignoring expected differences, such as optional components or hardware-specific fields. This focused comparison makes it easier to assess cluster compliance with the target configuration.

You can use the cluster-compare plugin in development, production, and support scenarios.

For more information about the cluster-compare plugin, see Overview of the cluster-compare plugin.

In this release, the Node Tuning Operator introduces support for deferring tuning updates. Administrators can schedule updates to be applied during a maintenance window with this feature.

For more information, see Deferring application of tuning changes.

With this release, the NUMA Resources Operator no longer creates a custom SELinux policy to enable the installation of Operator components on a target node. Instead, the Operator uses a built-in container SELinux policy. This change removes the additional node reboot that was previously required when applying a custom SELinux policy during an installation.

With this release, when you apply a performance profile, the Node Tuning Operator detects the platform and configures kernel arguments and other platform-specific options accordingly. This release adds support for detecting the following platforms:

With this release, you can use the PerformanceProfile custom resource (CR) to configure worker nodes on machines equipped with AMD EPYC Zen 4 CPUs (Genoa and Bergamo). These CPUs are fully supported.

Previously, the thinPoolConfig.overprovisionRatio field in the LVMCluster custom resource (CR) could be configured only during the creation of the LVMCluster CR. With this release, you can now update the thinPoolConfig.overprovisionRatio field even after creating the LVMCluster CR.

This feature provides the following new optional fields in the LVMCluster custom resource (CR):

For more information, see About the LVMCluster custom resource.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) with a Container Storage Interface (CSI) driver for the Common Internet File System (CIFS) dialect/Server Message Block (SMB) protocol. The CIFS/SMB CSI Driver Operator that manages this driver was introduced in OpenShift Container Platform 4.16 with Technology Preview status. In OpenShift Container Platform 4.18, it is now generally available.

For more information, see CIFS/SMB CSI Driver Operator.

The Secrets Store Container Storage Interface (CSI) Driver Operator, secrets-store.csi.k8s.io, allows OpenShift Container Platform to mount multiple secrets, keys, and certificates stored in enterprise-grade external secrets stores into pods as an inline ephemeral volume. The Secrets Store CSI Driver Operator communicates with the provider using gRPC to fetch the mount contents from the specified external secrets store. After the volume is attached, the data in it is mounted into the container’s file system. The Secrets Store CSI Driver Operator was available in OpenShift Container Platform 4.14 as a Technology Preview feature. OpenShift Container Platform 4.18 introduces this feature as generally available.

For more information about the Secrets Store CSI driver, see Secrets Store CSI Driver Operator.

For information about using the Secrets Store CSI Driver Operator to mount secrets from an external secrets store to a CSI volume, see Providing sensitive data to pods by using an external secrets store.

OpenShift Container Platform 4.16 introduced a new parameter, LastPhaseTransitionTime, which has a timestamp that is updated every time a persistent volume (PV) transitions to a different phase (pv.Status.Phase). For OpenShift Container Platform 4.18, this feature is generally available.

For more information about using the persistent volume last phase transition time parameter, see Last phase transition time.

OpenShift Container Platform 4.17 introduced the ability to deploy OpenShift Container Platform across multiple vSphere clusters (vCenters) as a Technology Preview feature. In OpenShift Container Platform 4.18, Multiple vCenter support is now generally available.

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

Prior to OpenShift Container Platform 4.18, the persistent volume (PV) reclaim policy was not always applied.

For a bound PV and persistent volume claim (PVC) pair, the ordering of PV-PVC deletion determined whether the PV delete reclaim policy was applied or not. The PV applied the reclaim policy if the PVC was deleted prior to deleting the PV. However, if the PV was deleted prior to deleting the PVC, then the reclaim policy was not applied. As a result of that behavior, the associated storage asset in the external infrastructure was not removed.

With OpenShift Container Platform 4.18, the PV reclaim policy is consistently always applied. This feature has Technical Preview status.

For more information, see Reclaim policy for persistent volumes.

For the Local Storage Operator (LSO), OpenShift Container Platform 4.18 improves the ability to remove Local Volumes (LVs) and Local Volume Sets (LVSs) by automatically removing artifacts, thus reducing the number of steps required.

For more information, see Removing a local volume or local volume set.

OpenShift Container Platform 4.18 introduces Container Storage Interface (CSI) volume group snapshots as a Technology Preview feature. This feature needs to be supported by the CSI driver. CSI volume group snapshots use a label selector to group multiple persistent volume claims (PVCs) for snapshotting. A volume group snapshot represents copies from multiple volumes that are taken at the same point-in-time. This can be useful for applications that contain multiple volumes.

OpenShift Data Foundation supports volume group snapshots.

For more information about CSI volume group snapshots, see CSI volume group snapshots.

The Google Cloud Platform Persistent Disk (GCP PD) Container Storage Interface (CSI) driver supports the C3 instance type for bare metal and N4 machine series. The C3 instance type and N4 machine series support the hyperdisk-balanced disks.

Additionally, hyperdisk storage pools are supported for large-scale storage. A hyperdisk storage pool is a purchased collection of capacity, throughput, and IOPS, which you can then provision for your applications as needed.

For OpenShift Container Platform 4.18, this feature is generally available.

For more information, see C3 instance type for bare metal and N4 machine series.

In OpenShift Container Platform 4.18, OpenStack Manila supports expanding Container Storage Interface (CSI) persistent volumes (PVs). This feature is generally available.

For more information, see Expanding persistent volumes and CSI drivers supported by OpenShift Container Platform.

In OpenShift Container Platform 4.18, Google Compute Platform (GCP) Filestore Container Storage Interface (CSI) storage supports Workload Identity. This allows users to access Google Cloud resources using federated identities instead of a service account key. For OpenShift Container Platform 4.18, this feature is generally available.

For more information, see Google Compute Platform Filestore CSI Driver Operator.

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:

The Shared Resource CSI Driver feature was deprecated in OpenShift Container Platform 4.17, and is now removed from OpenShift Container Platform 4.18. This feature is now generally available in Builds for Red Hat OpenShift 1.1. To use this feature, ensure you are using Builds for Red Hat OpenShift 1.1 or later.

The selected bundles feature is removed from the oc-mirror v2 Generally Available release. This change prevents issues where specifying the wrong Operator bundle version could break the Operators in a cluster. (OCPBUGS-49419)

The next minor release of OpenShift Container Platform is expected to use Kubernetes 1.32. Kubernetes 1.32 removed a deprecated API.

See the Deprecated API Migration Guide in the upstream Kubernetes documentation for the list of planned Kubernetes API removals.

See Navigating Kubernetes API deprecations and removals for information about how to check your cluster for Kubernetes APIs that are planned for removal.

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