Chapter 1. OpenShift Container Platform 4.20 release notes

Before this update, the self-signed loopback certificate for the Kubernetes API Server expired after one year. With this release, the expiration date of the certificate is extended to three years.

Before this update, deleting an istag resource with the --dry-run=server option unintentionally caused actual deletion of the image from the server. This unexpected deletion occurred due to the dry-run option being implemented incorrectly in the oc delete istag command. With this release, the dry-run option is wired to the oc delete istag command. As a result, the accidental deletion of image objects is prevented and the istag object remains intact when using the --dry-run=server option.

With this update, self-signed loopback certificates in API servers are prevented from expiring, and ensures a stable and secure connection within Kubernetes 4.16.z. This enhancement backports a solution from a newer version, cherry-picks a specific pull request and applies it to the selected version. This reduces the likelihood of service interruptions due to certificate-related issues, providing a more reliable user experience in Kubernetes 4.16.z deployments.

With this update, the communication flows matrix for OpenShift Container Platform is enhanced. The feature automatically generates services for open ports 17697 (TCP) and 6080 (TCP) on the primary node, and ensures that all open ports have corresponding endpoint slices. This results in accurate and up-to-date communication flows matrixes, improves the overall security and efficiency of the communication matrix, and provides a more comprehensive and reliable communication matrix for users.

The LVM Storage Operator now applies Kubernetes NetworkPolicy objects during installation to restrict network communication to only the required components. This feature enforces default network isolation for LVM Storage deployments on OpenShift Container Platform clusters.

When you create a persistent volume (PV) by using the LVM Storage Operator, the PV now includes the kubernetes.io/hostname label. This label shows which node the PV is located on, making it easier to identify the node associated with a workload. This change only applies to newly created PVs. Existing PVs are not modified.

The default namespace for the LVM Storage Operator is now openshift-lvm-storage. You can still install LVM Storage in a custom namespace.

OpenShift Container Platform 4.20 introduces the siteconfig-converter tool to help migrate managed clusters from using a SiteConfig custom resource (CR) to a ClusterInstance CR. Using a SiteConfig CR to define a managed cluster is deprecated and will be removed in a future release. The ClusterInstance CR provides a more unified and generic approach to defining clusters and is the preferred method for managing cluster deployments in the GitOps ZTP workflow.

Using the siteconfig-converter tool, you can convert SiteConfig CRs to ClusterInstance CRs and then incrementally migrate one or more clusters at a time. Existing and new pipelines run in parallel, so you can migrate clusters in a controlled, phased manner and without downtime.

For more information, see Migrating from SiteConfig CRs to ClusterInstance CRs.

You can configure an OpenShift Container Platform cluster with two control plane nodes and one local arbiter node to retain high availability (HA) while reducing infrastructure costs for your cluster.

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.

This feature is now Generally Available.

For more information, see Configuring a local arbiter node.

A two-node OpenShift cluster with fencing provides high availability (HA) with a reduced hardware footprint. This configuration is designed for distributed or edge environments where deploying a full three-node control plane cluster is not practical.

A two-node cluster does not include compute nodes. The two control plane machines run user workloads in addition to managing the cluster.

For more information, see Preparing to install a two-node OpenShift cluster with fencing.

With this release, you can deploy cluster extensions that use webhooks on clusters with the TechPreviewNoUpgrade feature set enabled.

For more information, see Supported extensions.

With this release, command line logs from virt-launcher pods can be collected across a Kubernetes cluster. JSON-encoded logs are saved at the path namespaces/<namespace-name>/pods/<pod-name>/virt-launcher.json, which facilitates troubleshooting and debugging of virtual machines.

With this release, the Cluster Version Operator (CVO) log level verbosity can be changed by the cluster administrator.

For more information, see Changing CVO log level.

OpenShift Container Platform 4.18 enabled you to install a VMware vSphere cluster with multiple network interface controllers (NICs) for a node as a Technology Preview feature. This feature is now Generally Available.

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, you can specify the location of a DNS private zone when installing a cluster on Google Cloud into a shared VPC. The private zone can be located in a service project that is distinct from the host project or main service project.

For more information, see Additional Google Cloud configuration parameters.

With this release, you can install a cluster on Azure using encrypted virtual networks. You are required to use Azure virtual machines that have the premiumIO parameter set to true. See Microsoft’s documentation about Creating a virtual network with encryption and Requirements and Limitations for more information.

With this release, if you install a cluster using IBM Cloud Paks, you must allow outbound access to icr.io and cp.icr.io on port 443. This access is required for IBM Cloud Pak container images. For more information, see Configuring your firewall.

With this release, you can install a cluster on Azure using Intel-based Confidential VMs. The following machine sizes are now supported:

For more information, see Enabling confidential VMs.

With this release, you can install your OpenShift Container Platform cluster on Azure with a dedicated data disk for etcd. This configuration attaches a separate managed disk to each control plane node and uses it only for etcd data, which can improve cluster performance and stability. This feature is available as a Technology Preview. For more information, see Configuring a dedicated disk for etcd.

With this release, you can install a bare-metal environment that supports multi-architecture capabilities. You can provision both x86_64 and aarch64 architectures from an existing x86_64 cluster by using virtual media, meaning you can manage a diverse hardware environment more efficiently.

For more information, see Configuring your cluster with multi-architecture compute machines.

With this release, the HostFirmwareComponents resource for bare metal describes network interface controllers (NICs). To update NIC host firmware components, the server must support Redfish and must permit you to use Redfish to update NIC firmware.

For more information, see About the HostFirmwareComponents resource.

In OpenShift Container Platform 4.17, a previously removed Kubernetes API was inadvertently reintroduced. It has been removed again in OpenShift Container Platform 4.20.

Before a cluster can be updated from OpenShift Container Platform 4.19 to 4.20, a cluster administrator must manually provide acknowledgment. This safeguard helps to prevent update issues that could occur if workloads, tools, or other components still depend on the Kubernetes API that has been removed in OpenShift Container Platform 4.20.

Administrators must take the following actions before proceeding with the cluster update:

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

For more information, see Kubernetes API removals.

Previously, when installing a cluster on IBM Power Virtual Server, you could only specify a name for an existing Transit Gateway or Virtual Private Cloud (VPC). As the uniqueness of names was not guaranteed, this could cause conflicts and installation failures. With this release, you can use Universally Unique Identifiers (UUIDs) for a Transit Gateway and VPC. By using unique identifiers, the installation program can unambiguously identify the correct Transit Gateway or VPC. This prevents the naming conflicts and the issue is resolved.

Updated boot images is now supported as a Technology Preview feature for VMware vSphere 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.

The following machine configuration changes no longer cause a reboot of nodes with on-cluster custom layered images:

For more information, see On-cluster image mode known limitations.

When image mode for OpenShift is configured, there are improvements to error reporting including the following changes:

You can now use the kernelType parameter in a MachineConfig object on nodes with on-cluster custom layered images in order to install a realtime kernel on the node. Previously, on nodes with on-cluster custom layered images the kernelType parameter was ignored. For information, see Adding a real-time kernel to nodes.

In clusters with slow, unreliable connections to an image registry, you can use a PinnedImageSet object to pull the images in advance, before they are needed, then associate those images with a machine config pool. This ensures that the images are available to the nodes in that pool when needed. The must-gather for the Machine Config Operator includes all PinnedImageSet objects in the cluster. For more information, see Pinning images to nodes.

The machine config nodes custom resource, which you can use to monitor the progress of machine configuration updates to nodes, is now generally available.

You can now view the status of updates to custom machine config pools in addition to the control plane and worker pools. The functionality for the feature has not changed. However, some of the information in the command output and in the status fields in the MachineConfigNode object has been updated. The must-gather for the Machine Config Operator now includes all MachineConfigNodes objects in the cluster. For more information, see About checking machine config node status.

This release includes a new security context constraint (SCC), named hostmount-anyuid-v2. This SCC provides the same features as the hostmount-anyuid SCC, but contains seLinuxContext: RunAsAny. This SCC was added because the hostmount-anyuid SCC was intended to allow trusted pods to access any paths on the host, but SELinux prevents containers from accessing most paths. The hostmount-anyuid-v2 allows host file system access as any UID, including UID 0, and is intended to be used instead of the privileged SCC. Grant with caution.

On clusters that manage machines with the Cluster API, you can specify additional constraints to determine whether your compute machines use AWS capacity reservations. For more information, see Capacity Reservation configuration options.

You can now configure a delay before the cluster autoscaler recognizes newly pending pods and schedules the pods to a new node by using the spec.scaleUp.newPodScaleUpDelay parameter in the ClusterAutoscaler CR. If the node remains unscheduled after the delay, the cluster autoscaler can scale up a new node. This delay gives the cluster autoscaler additional time to locate an appropriate node or it can wait for space on an existing pod to become available. For more information, see Configuring the cluster autoscaler.

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

With this release, you can configure log verbosity for Metrics Server. You can set a numeric verbosity level to control the amount of logged information, where higher numbers increase the logging detail.

For more information, see Setting log levels for monitoring components.

OpenShift Container Platform 4.20 updates Red Hat OpenShift Service Mesh to version 3.1.0, which now supports Red Hat OpenShift AI. This version update incorporates essential CVE fixes, resolves other bugs, and upgrades Istio to version 1.26.2 for improved security and performance. See the Service Mesh 3.1.0 release notes for more information.

The Cluster Network Operator (CNO) now supports enabling Border Gateway Protocol (BGP) routing. With BGP, you can import and export routes to the underlying provider network and use multi-homing, link redundancy, and fast convergence. BGP configuration is managed with the FRRConfiguration custom resource (CR).

When upgrading from an earlier version of OpenShift Container Platform in which you installed the MetalLB Operator, you must manually migrate your custom frr-k8s configurations from the metallb-system namespace to the openshift-frr-k8s namespace. To move these CRs, enter the following commands:

After the migration is complete, you can remove the FRR-K8s custom resources from the metallb-system namespace.

For more information, see About BGP routing.

With route advertisements enabled, the OVN-Kubernetes network plugin supports the direct advertisement of routes for pods and services associated with cluster user-defined networks (CUDNs) to the provider network. This feature enables some of the following benefits:

For more information, see About route advertisements.

Preconfigured user-defined network endpoints is available as a Technology Preview and controlled by the feature gate, PreconfiguredUDNAddresses. You can now explicitly control the overlay network configuration including: IP address, MAC address, and default gateway. This feature is available for Layer 2 as part of the ClusterUserDefinedNetwork (CUDN) custom resource (CR). Administrators can preconfigure endpoints to migrate KubeVirt virtual machines (VMs) without disruption. To enable the feature use the new fields, reservedSubnets, infrastructureSubnets, and defaultGatewayIPs, found in the CUDN CR. For more information about the configurations, see Additional configuration details for user-defined networks. Currently, static IP addresses are only supported for the ClusterUserDefinedNetworks CR and only for use with MTV.

If you used the configure-ovs.sh shell script to set a br-ex bridge during cluster installation, you can migrate the br-ex bridge to NMState as a postinstallation task. For more information, see Migrating a configured br-ex bridge to NMState.

You can now configure enhanced log reduction for the PTP Operator to reduce the volume of logs generated by the linuxptp-daemon.

This feature provides a periodic summary of filtered logs, which is not available with basic log reduction. Optionally, you can set a specific interval for the summary logs and a threshold in nanoseconds for the master offset logs.

For more information, see Configuring enhanced PTP logging.

With this release, you can configure PTP ordinary clocks with added redundancy on AArch64 architecture nodes that use the following dual-port NICs only:

This feature is available as a Technology Preview. For more information, see Using dual-port NICs to improve redundancy for PTP ordinary clocks.

In this release you can now specify the transmit hash policy for load balancing across the aggregated interfaces with the xmitHashPolicy as part of bond CNI plugin configuration. This feature is available as a Technology Preview.

For more information, see Configuration for a Bond CNI secondary network.

With OpenShift Container Platform 4.20, you can now create and manage SR-IOV networks directly within your application namespaces. This new feature provides greater control over your network configurations and helps simplify your workflow.

Previously, creating an SR-IOV network required a cluster administrator to configure it for you. Now, you can manage these resources directly in your own namespace, which offers several key benefits:

For more information, see Configuring namespaced SR-IOV resources.

With this release, OpenShift Container Platform includes unnumbered BGP peering. This was previously available as a Technology Preview feature. You can use the spec.interface field of the BGP peer custom resource to configure unnumbered BGP peering.

For more information, see Configuring the integration of MetalLB and FRR-K8s .

This Technology Preview feature introduces the PF Status Relay Operator. The Operator uses Link Aggregation Control Protocol (LACP) as a health check to detect upstream switch failures, enabling high availability for workloads that use pod-level bonding with SR-IOV network virtual functions (VF).

Without this feature, an upstream switch can fail while the underlying physical function (PF) still reports an up state. VFs attached to the PF also remain up, causing pods to send traffic to a dead endpoint and leading to packet loss.

The PF Status Relay Operator prevents this by monitoring the LACP status of the PF. When a failure is detected, the Operator forces the link state of the attached VFs down, triggering the pod’s bond to fail over to a backup path. This ensures the workload remains available and minimizes packet loss.

For more information, see High availability for pod-level bonds on SR-IOV networks.

With this release, OpenShift Container Platform deploys Kubernetes network policies to additional system namespaces to control ingress and egress traffic. It is anticipated that future releases might include network policies for additional system namespaces and Red Hat Operators.

With this release, the PTP Operator provides unassisted holdover as a Technology Preview feature. When the upstream timing signal is lost, the PTP Operator automatically places PTP devices configured as either a boundary clock or a time slave clock into holdover mode. Automatic placement into holdover mode helps to maintain a continuous and stable time source for cluster nodes, minimizing time synchronization disruptions.

For more information, see Configuring PTP devices.

Support for sigstore ClusterImagePolicy and ImagePolicy objects is now generally available. The API version is now config.openshift.io/v1. For more information, see Manage secure signatures with sigstore.

Support for deploying pods and containers into Linux user namespaces is now generally available and enabled by default. 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. This change also includes two new security context constraints, restricted-v3 and nested-container, that are specifically designed for use with user namespaces. You can also configure the /proc file system in pods as unmasked. For more information, see Running pods in Linux user namespaces.

By using the in-place pod resizing feature, you can apply a resize policy to change the CPU and memory resources for containers within a running pod without re-creating or restarting the pod. For more information, see Manually adjust pod resource levels.

You can you use an image volume to mount an Open Container Initiative (OCI)-compliant container image or artifact directly into a pod. For more information, see Mounting an OCI image into a pod.

You can now enable pods to request GPUs based on specific device attributes, such as product name, GPU memory capacity, compute capability, vendor name, and driver version. These attributes are exposed by the by using a third-party DRA resource driver that you install. For more information, see Allocating GPUs to pods.

Formerly Technology Preview and now Generally Available, the oc adm upgrade recommend command allows system administrators to perform a pre-update check on their OpenShift Container Platform clusters using the command line interface (CLI). The pre-update check helps identify potential issues, enabling users to address them before initiating an update. By running the precheck command and inspecting the output, users can prepare for updating their cluster and make informed decisions about when to start an update.

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

Formerly Technology Preview and now Generally Available, the oc adm upgrade status command allows cluster administrators to get high-level summary information about the state of their OpenShift Container Platform cluster update using the command line interface (CLI). Three types of information are provided when you enter the command: control plane information, worker node information, and health insights.

The command is not currently supported on Hosted Control Plane (HCP) clusters.

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

Operand images, dynamically deployed by Operator controllers at runtime, are typically referenced by environment variables within the controller’s deployment template.

Before OpenShift Container Platform 4.20, while oc-mirror plugin v2 could access these environment variables, it attempted to mirror all values, including non-image references, for example, log levels, leading to failures. With this update, OpenShift Container Platform identifies and mirrors only the container images referenced in these environment variables.

For more information, see ImageSet configuration parameters for oc-mirror plugin v2.

With this release, the following base images for Operator projects are updated for compatibility with OpenShift Container Platform 4.20. 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).

With this release, the Red Hat-provided Operator catalogs have moved from OperatorHub to the software catalog and the Operators navigation item is renamed to Ecosystem in the console. The unified software catalog presents Operators, Helm charts, and other installable content in the same console view.

To manage the default or custom catalog sources, you still interact with OperatorHub custom resource (CR) in the console or CLI.

With this release, you can configure your AWS OpenShift Container Platform cluster to use STS even if you did not do so during installation.

For more information, see Enabling AWS Security Token Service (STS) on an existing cluster.

With this update, kdump is now Generally Available for all supported architectures, including x86_64, arm64, s390x, and ppc64le. This enhancement enables users to diagnose and resolve kernel problems more efficiently.

RHCOS introduces version 2.20.0 of Ignition. This enhancement supports partitioning disks with mounted partitions using the partx utility, which is now included with dracut module installations. Additionally, this update adds support for Proxmox Virtual Environment.

RHCOS now includes Butane version 0.23.0.

RHCOS now includes Afterburn version 5.7.0. This update adds support for Proxmox Virtual Environment.

With this release, the coreos-installer utility is updated to version 0.23.0.

In OpenShift Container Platform 4.20, the NUMA Resources Operator automatically enables high availability (HA) mode by default. In this mode, the NUMA Resources Operator creates one scheduler replica for each control-plane node in the cluster to ensure redundancy. This default behavior occurs if the spec.replicas field is not specified in the NUMAResourcesScheduler custom resource. Alternatively, you can explicitly set a specific number of scheduler replicas to override the default HA behavior or disable the scheduler entirely by setting the spec.replicas field to 0. The maximum number of replicas is 3, even if the number of control plane nodes exceeds 3.

For more information, see Managing high availability (HA) for the NUMA-aware scheduler.

With this release, the NUMA Resources Operator can now manage control plane nodes that are configured as schedulable. This capability allows you to deploy topology-aware workloads on control plane nodes, which is especially useful in resource-constrained environments like compact clusters.

This enhancement helps the NUMA Resources Operator schedule your NUMA-aware pods on the node with the most suitable NUMA topology, even on control plane nodes.

For more information, see NUMA Resources Operator support for schedulable control-plane nodes.

With this release, Receive Packet Steering (RPS) is no longer configured when Performance Profile is applied. The RPS configuration affects containers that perform networking system calls, such as send, directly within latency-sensitive threads. To avoid latency impacts when RPS is not configured, move networking calls to helper threads or processes.

The previous RPS configuration resolved latency issues at the expense of overall pod kernel networking performance. The current default configuration promotes transparency by requiring developers to address the underlying application design instead of obscuring performance impacts.

To revert to the previous behavior, add the performance.openshift.io/enable-rps annotation to the PerformanceProfile manifest:

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: example-performanceprofile
  annotations:
    performance.openshift.io/enable-rps: "enable"

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: example-performanceprofile
  annotations:
    performance.openshift.io/enable-rps: "enable"

With this release, you can use the PerformanceProfile custom resource to configure worker nodes on machines equipped with Intel Sierra Forest CPUs. These CPUs are supported when configured with a single NUMA domain (NPS=1).

With this release, you can use the PerformanceProfile custom resource to configure worker nodes on machines equipped with AMD Turin CPUs. These CPUs are fully supported when configured with a single NUMA domain (NPS=1).

This new feature enhances TLS certificate rotations in OpenShift Container Platform, ensuring 95% expected cluster availability. It is particularly beneficial for high-transaction-rate clusters and single-node OpenShift deployments, ensuring seamless operation even under heavy loads.

With this update, the etcd product documentation is updated to include additional requirements for reducing OpenShift Container Platform cluster latency. This update clarifies the prerequisites and setup procedures for using etcd, resulting in an improved user experience. As a result, this feature introduces support for Transport Layer Security (TLS) 1.3 in etcd, which enhances security and performance for data transmission, and enables etcd to comply with the latest security standards, reducing potential vulnerabilities. The improved encryption ensures more secure communication between etcd and its clients. For more information, see Cluster latency requirements for etcd.

The Secrets Store CSI Driver Operator version 4.20 is now based on the upstream v1.5.2 release. The Secrets Store CSI Driver Operator now applies Kubernetes NetworkPolicy objects during installation to restrict network communication to only the required components.

The volume populators feature allows you to create pre-populated volumes.

OpenShift Container Platform 4.20 introduces a new field dataSourceRef for volume populator functionality that expands the objects that can be used as a data source for pre-population of volumes, from only persistent volume claims (PVC) and snapshots, to any appropriate custom resource (CR).

OpenShift Container Platform now ships volume-data-source-validator, which reports events on PVCs that use a volume populator without a corresponding VolumePopulator instance. Previous OpenShift Container Platform versions did not require VolumePopulator instances, so if you are upgrading from 4.12, or later, you might receive events about unregistered populators. If you installed volume-data-source-validator yourself previously, you can remove your version.

The volume populators feature, which was introduced in OpenShift Container Platform 4.12 as a Technology Preview feature, is now supported as generally available.

Volume population is enabled by default. However, OpenShift Container Platform does not ship with any volume populators.

For more information about volume populators, see Volume populators.

By enabling performance plus, the input/output operations per second (IOPS) and throughput limits can be increased for the following types of disks that are 513 GiB, and larger:

This feature is generally available in OpenShift Container Platform 4.20.

For more information about performance plus, see Performance plus for Azure Disk.

Changed block tracking enables efficient and incremental backups and disaster recovery for persistent volumes (PVs) managed by Container Storage Interface (CSI) drivers that support this feature.

Changed block tracking allows consumers to requests a list of blocks that have changed between two snapshots, which is useful for backup solutions vendors. By only backing up changed blocks, rather than entire volumes, back up processes are more efficient.

For more information about changed block tracking, see this KB article.

OpenShift Container Platform 4.20 introduces AWS Elastic File Storage (EFS) One Zone volume support as generally available. With this feature, if file system Domain Name System (DNS) resolution fails, the EFS CSI driver can fall back to mount targets. A mount target serves as a network endpoint that allows AWS EC2 instances or other AWS compute instances within a Virtual Private Cloud (VPC) to connect to, and mount, an EFS file system.

For more information about One Zone, see Support for One Zone.

Certain operations of a volume can cause pod startup delays, which might cause pod timeouts.

fsGroup: For volumes with many files, pod startup timeouts can occur because, by default, OpenShift Container Platform recursively changes ownership and permissions for the contents of each volume to match the fsGroup specified in a pod’s securityContext when that volume is mounted. This can be time consuming, slowing pod startup. You can use the fsGroupChangePolicy parameter inside a securityContext to control the way that OpenShift Container Platform checks and manages ownership and permissions for a volume.

Changing this parameter at the pod level was introduced in OpenShift Container Platform 4.10. In 4.20, you can set this parameter at the namespace level, in addition to the pod level, as a generally available feature.

SELinux: SELinux (Security-Enhanced Linux) is a security mechanism that assigns security labels (contexts) to all objects (files, processes, network ports, etc.) on a system. These labels determine what a process can access. When a pod starts, the container runtime recursively relabels all files on a volume to match a pod’s SELinux context. For volumes with a lot of files, this can significantly increase pod startup times. Mount option specifies avoiding recursive relabeling of all files by attempting to mount the volume with the correct SELinux label directly using the -o context mount option, thus helping to avoid pod timeout problems.

RWOP and SELinux mount option: ReadWriteOncePod (RWOP) persistent volumes use the SELinux mount feature by default. Mount option was introduced in OpenShift Container Platform 4.15 as a Technology Preview feature, and became generally available in 4.16.

RWO and RWX and SELinux mount option: ReadWriteOnce (RWO) and ReadWriteMany (RWX) volumes use recursive relabeling by default. Mount option for RWO/RWX was introduced in OpenShift Container Platform 4.17 as a Developer Preview feature, but is now supported in 4.20 as a Technology Preview feature.

To assist you with the upcoming move to the mount option default, OpenShift Container Platform 4.20 reports SELinux-related conflicts when creating pods, and on running pods, to make you aware of potential conflicts, and to help you resolve them. For more information about this reporting, see this KB article.

If you are unable to resolve the SELinux-related conflicts, you can proactively opt-out of the future move to mount option as default for selected pods or namespaces.

In OpenShift Container Platform 4.20, you can evaluate the mount option feature for RWO and RWX volumes as a Technology Preview feature.

For more information about fsGroup, see Reducing pod timeouts using fsGroup.

For more information about SELinux, see Reducing pod timeouts using seLinuxChangePolicy.

Before 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 before deleting the PV. However, if the PV was deleted before 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.

Starting with OpenShift Container Platform 4.18, the PV reclaim policy is consistently always applied as a Technical Preview feature. With OpenShift Container Platform 4.20, this feature is generally available.

For more information, see Reclaim policy for persistent volumes.

By default, OpenShift Container Platform creates Manila storage classes that provide access to all IPv4 clients, with the possibility of updating it to a single IP address or subnet. In OpenShift Container Platform 4.20, you can limit client access by defining custom storage classes that use multiple client IP addresses or subnets by using the nfs-ShareClient parameter.

This feature is generally available in OpenShift Container Platform 4.20.

For more information, see Customizing Manila share access rules.

To enhance usability and provide both Security Token Service (STS) and non-STS support, the Amazone Web Serivces (AWS) Elastic File Service (EFS) cross account support procedure has been revised.

To view the revised procedure, see AWS EFS cross account support.

Before this update, the Container image form flow provided only a limited set of predefined icons for applications.

With this update, you can add custom icons when you import applications through the Container image form. For existing applications, apply the app.openshift.io/custom-icon annotation to add a custom icon to the corresponding Topology node.

As a result, you can better identify applications in the Topology view and organize your projects more clearly.

The use of Confidential Computing with AMD Secure Encrypted Virtualization (AMD SEV) on Google Cloud has been deprecated and might be removed in a future release.

You can use AMD Secure Encrypted Virtualization Secure Nested Paging (AMD SEV-SNP) instead.

Support for Docker v2 registries is deprecated and is planned for removal in a future release. A registry that supports the Open Container Initiative (OCI) specification will be required for all mirroring operations in a future release. Additionally, oc-mirror v2 now only generates custom catalog images in the OCI format, whereas the deprecated oc-mirror v1 still supports the Docker v2 format.

The Red Hat Marketplace is deprecated. Customers who use the partner software from the Marketplace should contact the software vendor about how to migrate from the Marketplace Operator to an Operator in the Red Hat Ecosystem Catalog. It is expected that the Marketplace index will be removed in an upcoming OpenShift Container Platform release. For more information, see Sunset of the Red Hat Marketplace, operated by IBM.

OpenShift Container Platform 4.20 removed the following Kubernetes APIs. You must migrate your manifests, automation, and API clients to use the new, supported API versions before updating to 4.20. For more information about migrating removed APIs, see the Kubernetes documentation.

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