Chapter 1. OpenShift Container Platform 4.10 release notes

OpenShift Container Platform 4.10 now includes a getting started guide. Getting Started with OpenShift Container Platform defines basic terminology and provides role-based next steps for developers and administrators.

The tutorials walk new users through the web console and the OpenShift CLI (oc) interfaces. New users can accomplish the following tasks through the Getting Started:

For more information, see Getting Started with OpenShift Container Platform.

The coreos-installer utility now has iso customize and pxe customize subcommands for more flexible customization when installing RHCOS on bare metal from the live ISO and PXE images.

This includes the ability to customize the installation to fetch Ignition configs from HTTPS servers that use a custom certificate authority or self-signed certificate.

RHCOS now uses Red Hat Enterprise Linux (RHEL) 8.4 packages in OpenShift Container Platform 4.10. These packages provide you the latest fixes, features, and enhancements, such as NetworkManager features, as well as the latest hardware support and driver updates.

The OpenShift Container Platform 4.10 installer uses new default component types for installations on AWS. The installation program uses the following components by default:

Previously, when a user installed OpenShift Container Platform on a bare metal installer-provisioned infrastructure, they had nowhere to configure custom network interfaces, such as static IPs or vLANs to communicate with the Ironic server.

When configuring a Day 1 installation on bare metal only, users can now use the API in the install-config.yaml file to customize the network configuration (networkConfig). This configuration is set during the installation and provisioning process and includes advanced options, such as setting static IPs per host.

OpenShift Container Platform 4.10 is now supported on ARM based AWS EC2 and bare-metal platforms. Instance availability and installation documentation can be found in Supported installation methods for different platforms.

The following features are supported for OpenShift Container Platform on ARM:

The following Operators are supported for OpenShift Container Platform on ARM:

OpenShift Container Platform 4.10 introduces support for installing a cluster on IBM Cloud using installer-provisioned infrastructure in Technology Preview.

The following limitations apply for IBM Cloud using IPI:

For more information, see Preparing to install on IBM Cloud.

OpenShift Container Platform 4.10 introduces support for thin-provisioned disks when you install a cluster using installer-provisioned infrastructure. You can provision disks as thin, thick, or eagerZeroedThick. For more information about disk provisioning modes in VMware vSphere, see Installation configuration parameters.

Red Hat Enterprise Linux CoreOS (RHCOS) Amazon Machine Images (AMIs) are now available for AWS GovCloud regions. The availability of these AMIs improves the installation process because you are no longer required to upload a custom RHCOS AMI to deploy a cluster.

For more information, see Installing a cluster on AWS into a government region.

Beginning with OpenShift Container Platform 4.10, if you configure a cluster with an existing IAM role, the installation program no longer adds the shared tag to the role when deploying the cluster. This enhancement improves the installation process for organizations that want to use a custom IAM role, but whose security policies prevent the use of the shared tag.

To install a CSI driver on a cluster running on vSphere, you must have the following components installed:

Components with versions earlier than those above are still supported, but are deprecated. These versions are still fully supported, but version 4.11 of OpenShift Container Platform will require vSphere virtual hardware version 15 or later.

OpenShift Container Platform 4.10 introduces the ability for installing a cluster on Alibaba Cloud using installer-provisioned infrastructure in Technology Preview. This type of installation lets you use the installation program to deploy a cluster on infrastructure that the installation program provisions and the cluster maintains.

OpenShift Container Platform 4.10 introduces support for installing a cluster on Azure Stack Hub using installer-provisioned infrastructure. This type of installation lets you use the installation program to deploy a cluster on infrastructure that the installation program provisions and the cluster maintains.

For more information, see Installing a cluster on Azure Stack Hub with an installer-provisioned infrastructure.

OpenShift Container Platform 4.10 adds support for consuming conditional update paths provided by the OpenShift Update Service. Conditional update paths convey identified risks and the conditions under which those risks apply to clusters. The Administrator perspective on the web console only offers recommended upgrade paths for which the cluster does not match known risks. However, OpenShift CLI (oc) 4.10 or later can be used to display additional upgrade paths for OpenShift Container Platform 4.10 clusters. Associated risk information including supporting documentation references is displayed with the paths. The administrator may review the referenced materials and choose to perform the supported, but no longer recommended, upgrade.

For more information, see Conditional updates and Updating along a conditional upgrade path.

This release introduces the oc-mirror OpenShift CLI (oc) plugin as a Technology Preview. You can use the oc-mirror plugin to mirror images in a disconnected environment.

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

You can now install a cluster on Red Hat OpenStack Platform (RHOSP) for which compute machines run on Open vSwitch with the Data Plane Development Kit (OVS-DPDK) networks. Workloads that run on these machines can benefit from the performance and latency improvements of OVS-DPDK.

For more information, see Installing a cluster on RHOSP that supports DPDK-connected compute machines.

You can now select compute machine affinity when you install a cluster on RHOSP. By default, compute machines are deployed with a soft-anti-affinity server policy, but you can also choose anti-affinity or soft-affinity policies.

Starting with OpenShift Container Platform 4.10, the ability to create OpenShift console dynamic plugins is now available as a Technology Preview feature. You can use this feature to customize your interface at runtime in many ways, including:

For more information about the dynamic plugin, see Adding a dynamic plugin to the OpenShift Container Platform web console.

With this update, you can now view debug terminals in the web console. When a pod has a container that is in a CrashLoopBackOff state, a debug pod can be launched. A terminal interface is displayed and can be used to debug the crash looping container.

Additionally, the pod status pop-up window now provides links to the Logs and Events tabs of the pod details page.

With this update, you can customize workload notifications on the User Preferences page. User workload notifications under the Notifications tab allows you to hide user workload notifications that appear on the Cluster Overview page or in your drawer.

With this update, non-admin users are now able to view their usage of the AppliedClusterResourceQuota on the Project Overview, ResourceQuotas, and API Explorer pages to determine the cluster-scoped quota available for use. Additionally, AppliedClusterResourceQuota details can now be found on the Search page.

OpenShift Container Platform now enables you to view support level information about your cluster on the Overview Details card, in the Cluster Settings, in the About modal, and adds a notification to your notifications drawer when your cluster is unsupported. From the Overview page, you can manage subscription settings under the Service Level Agreement (SLA).

When you create a service that uses multiple IP address families, you must explicitly specify ipFamilyPolicy: PreferDualStack or ipFamilyPolicy: RequireDualStack in your Service object definition. This change breaks backward compatibility with earlier releases of OpenShift Container Platform.

For more information, see BZ#2045576.

After cluster installation, if you are using the OpenShift SDN cluster network provider or the OVN-Kubernetes cluster network provider, you can change your hardware MTU and your cluster network MTU values. Changing the MTU across the cluster is disruptive and requires that each node is rebooted several times. For more information, see Changing the cluster network MTU.

The OVN-Kubernetes CNI network provider adds support for configuring how egress traffic is sent to the node gateway. By default, egress traffic is processed in OVN to exit the cluster and traffic is not affected by specialized routes in the kernel routing table.

This enhancement adds a gatewayConfig.routingViaHost field. With this update, the field can be set at runtime as a post-installation activity and when it is set to true, egress traffic is sent from pods to the host networking stack. This update benefits highly specialized installations and applications that rely on manually configured routes in the kernel routing table.

This enhancement has an interaction with the Open vSwitch hardware offloading feature. With this update, when the gatewayConfig.routingViaHost field is set to true, you do not receive the performance benefits of the offloading because egress traffic is processed by the host networking stack.

For configuration information, see Configuration for the OVN-Kubernetes CNI cluster network provider.

The following metrics are now available for clusters. The metric names that start with sdn_controller are unique to the OpenShift SDN CNI network provider. The metric names that start with ovn are unique to the OVN-Kubernetes CNI network provider:

The ovnkube_master_resource_update_total metric is removed for the 4.10 release.

When using the network policy functionality in the OpenShift Container Platform web console, the pods affected by a policy are listed. The list changes as the combined namespace and pod selectors in these policy sections are modified:

The list of impacted pods includes only those pods accessible by the user.

The oc adm must-gather command is enhanced in a way that simplifies collecting network packet captures.

Previously, oc adm must-gather could start a single debug pod only. With this enhancement, you can start a debug pod on multiple nodes at the same time.

You can use the enhancement to run packet captures on multiple nodes at the same time to simplify troubleshooting network communication issues. A new --node-selector argument provides a way to identify which nodes you are collecting packet captures for.

For more information, see Network trace methods and Collecting a host network trace.

Bonding at the pod level is vital to enable workloads inside pods that require high availability and more throughput. With pod-level bonding, you can create a bond interface from multiple single root I/O virtualization (SR-IOV) virtual function interfaces in kernel mode interface. The SR-IOV virtual functions are passed into the pod and attached to a kernel driver.

Scenarios where pod-level bonding is required include creating a bond interface from multiple SR-IOV virtual functions on different physical functions. Creating a bond interface from two different physical functions on the host can be used to achieve high availability at pod level.

As a cluster administrator, you can associate one or more egress IP addresses with a namespace. An egress IP address ensures that a consistent source IP address is associated with traffic from a particular namespace that is leaving the cluster.

For the OVN-Kubernetes and OpenShift SDN cluster network providers, you can configure an egress IP address on the following public cloud providers:

To learn more, refer to the respective documentation for your cluster network provider:

If you use the OpenShift SDN cluster network provider, you can now use egress rules in network policy with ipBlock and ipBlock.except. You define egress policies in the egress array of the NetworkPolicy object.

For more information, refer to About network policy.

This enhancement adds the ability to configure global HTTP traffic compression on the HAProxy Ingress Controller for specific MIME types. This update enables gzip-compression of your ingress workloads when there are large amounts of compressible routed traffic.

For more information, see Using router compression.

A cluster administrator can now configure DNS servers to allow DNS name resolution through the configured servers for the default domain. A DNS forwarding configuration can have both the default servers specified in the /etc/resolv.conf file and the upstream DNS servers.

For more information, see Using DNS forwarding.

This enhancement adds the ability to manually change the log level for an Operator individually or a cluster as a whole.

For more information, see Setting the CoreDNS log level

You can now set the maximum length of the syslog message in the Ingress Controller to any value between 480 and 4096 bytes.

For more information, see Ingress Controller configuration parameters.

You can now set the CoreDNS forwarding policy through the DNS Operator. The default value is Random, and you can also set the value to RoundRobin or Sequential.

For more information, see Using DNS forwarding.

You can now configure Open vSwitch hardware offloading to increase data processing performance on compatible bare metal nodes. Hardware offloading is a method for processing data that removes data processing tasks from the CPU and transfers them to the dedicated data processing unit of a network interface controller. Benefits of this feature include faster data processing, reduced CPU workloads, and lower computing costs.

For more information, see Configuring hardware offloading.

You can now create DNS records by using the Red Hat External DNS Operator on cloud providers such as AWS, Azure, and GCP. You can install the External DNS Operator using OperatorHub. You can use parameters to configure ExternalDNS as required.

For more information, see Understanding the External DNS Operator.

Cluster administrators can now configure the Ingress Controller endpoint publishing strategy to change the load-balancer scope between Internal and External in OpenShift Container Platform.

For more information, see Ingress Controller endpoint publishing strategy.

For clusters that run on Red Hat OpenStack Platform (RHOSP), you can enable Open vSwitch (OVS) hardware offloading.

For more information, see Enabling OVS hardware offloading.

For clusters that run on RHOSP, Kuryr now only creates Neutron networks and subnets for namespaces that have at least one pod on the pods network. Additionally, pools in a namespace are populated after at least one pod on the pods network is created in the namespace.

You can now deploy a cluster on a Red Hat OpenStack Platform (RHOSP) deployment that uses a distributed compute node (DCN) configuration. This deployment configuration has several limitations:

Clusters that run on RHOSP can now use Cloud Provider OpenStack. This capability is available as part of the TechPreviewNoUpgrade feature set.

OpenShift Container Platform now provides a networkConfig configuration setting for installer-provisioned clusters, which takes an NMState YAML configuration to configure host interfaces. During installer-provisioned installations, you can add the networkConfig configuration setting and the NMState YAML configuration to the install-config.yaml file. Additionally, you can add the networkConfig configuration setting and the NMState YAML configuration to the bare metal host resource when using the Bare Metal Operator.

The most common use case for the networkConfig configuration setting is to set static IP addresses on a host’s network interface during installation or while expanding the cluster.

For more information, see Configuring host network interfaces in the install-config.yaml file.

You can now specify multiple network interfaces in a PtpConfig profile to allow nodes running RAN vDU applications to serve as a Precision Time Protocol Telecom Boundary Clock (PTP T-BC). Interfaces configured as boundary clocks now also support PTP fast events.

For more information, see Configuring linuxptp services as boundary clock.

Intel 800-Series Columbiaville NICs are now fully supported for interfaces configured as boundary clocks or ordinary clocks. Columbiaville NICs are supported in the following configurations:

For more information, see Configuring PTP devices.

OpenShift Container Platform now provides the Kubernetes NMState Operator for bare-metal, IBM Power, IBM Z, and LinuxONE installations. The Kubernetes NMState Operator is still a Technology Preview for all other platforms. See About the Kubernetes NMState Operator for additional details.

SR-IOV support is now available for Mellanox MT2892 cards.

As an administrator, you can now install the Network Observability Operator to observe the network traffic for your OpenShift Container Platform cluster in the console. You can view and monitor the network traffic data in different graphical representations. The Network Observability Operator uses eBPF technology to create the network flows. The network flows are enriched with OpenShift Container Platform information, and stored in Loki. You can use the network traffic information for detailed troubleshooting and analysis.

The Network Observability Operator is General Availability (GA) status in the 4.12 release of OpenShift Container Platform and is also supported in OpenShift Container Platform 4.10.

For more information, see Network Observability.

The following enhancements to MetalLB and the MetalLB Operator are included in this release:

For more information, see About MetalLB and the MetalLB Operator.

OpenShift Container Platform supports the HostFirmwareSettings and FirmwareSchema resources. When deploying OpenShift Container Platform on bare metal hosts, there are times when you need to make changes to the host either before or after provisioning. This can include inspecting the host’s firmware and BIOS details. There are two new resources that you can use with the Bare Metal Operator (BMO):

See Bare metal configuration for additional details.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for AliCloud Disk. The AliCloud Disk Driver Operator that manages this driver is generally available, and enabled by default in OpenShift Container Platform 4.10.

For more information, see AliCloud Disk CSI Driver Operator.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for Azure File. The Azure File Driver Operator that manages this driver is in Technology Preview.

For more information, see Azure File CSI Driver Operator.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for IBM Virtual Private Cloud (VPC) Block. The IBM VPC Block Driver Operator that manages this driver is generally available, and enabled by default in OpenShift Container Platform 4.10.

For more information, see IBM VPC Block CSI Driver Operator.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for vSphere. This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.8 and is now generally available and enabled by default in OpenShift Container Platform 4.10.

For more information, see vSphere CSI Driver Operator.

vSphere CSI Driver Operator installation requires:

Clusters are still upgraded even if the preceding conditions are not met, but it is recommended that you meet these conditions to have a supported vSphere CSI Operator Driver.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for Azure Disk. This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.8 and is now generally available, and enabled by default in OpenShift Container Platform 4.10.

For more information, see Azure Disk CSI Driver Operator.

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for AWS Elastic File Storage (EFS). This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.9 and is now generally available in OpenShift Container Platform 4.10.

For more information, see AWS EFS CSI Driver Operator.

Starting with OpenShift Container Platform 4.8, automatic migration for in-tree volume plugins to their equivalent Container Storage Interface (CSI) drivers became available as a Technology Preview feature. This feature now supports automatic migration for the Azure File in-tree plugin to the Azure File CSI driver.

For more information, see CSI automatic migration.

Starting with OpenShift Container Platform 4.8, automatic migration for in-tree volume plugins to their equivalent Container Storage Interface (CSI) drivers became available as a Technology Preview feature. This feature now supports automatic migration for the vSphere in-tree plugin to the vSphere CSI driver.

For more information, see CSI automatic migration.

If a storage volume contains many files (roughly 1,000,000 or greater), you may experience pod timeouts.

OpenShift Container Platform 4.10 introduces the ability to use fsGroup and fsGroupChangePolicy to skip recursive permission change for the storage volume, therefore helping to avoid pod timeout problems.

For more information, see Using fsGroup to reduce pod timeouts.

When an Operator is installed by Operator Lifecycle Manager (OLM), a simplified copy of its cluster service version (CSV) is created in every namespace that the Operator is configured to watch. These CSVs are known as copied CSVs; they identify controllers that are actively reconciling resource events in a given namespace.

On large clusters, with namespaces and installed Operators potentially in the hundreds or thousands, copied CSVs can consume an untenable amount of resources, such as OLM’s memory usage, cluster etcd limits, and networking bandwidth. To support these larger clusters, cluster administrators can now disable copied CSVs for Operators that are installed with the AllNamespaces mode.

For more details, see Configuring Operator Lifecycle Manager features.

Operators with specific dependency requirements can now use complex constraints or requirement expressions. The new olm.constraint bundle property holds dependency constraint information. A message field allows Operator authors to convey high-level details about why a particular constraint was used.

For more details, see Operator Lifecycle Manager dependency resolution.

Operator Lifecycle Manager (OLM) components, including Operator catalogs, can now run entirely on Hypershift-managed control planes. This capability does not incur any cost to tenants on worker nodes.

Previously, the default Operator catalogs did not support ARM. With this enhancement, Operator Lifecycle Manager (OLM) adds default Operator catalogs to ARM clusters. As a result, the OperatorHub now includes content by default for Operators that support ARM. (BZ#1996928)

The standard Helm-based Operator support in the Operator SDK has limited functionality compared to the Go-based and Ansible-based Operator support that has reached the Auto Pilot capability (level V) in the Operator maturity model.

Starting in OpenShift Container Platform 4.10 as a Technology Preview feature, the Operator SDK includes the Hybrid Helm Operator to enhance the existing Helm-based support abilities through Go APIs. Operator authors can generate an Operator project beginning with a Helm chart, and then add advanced, event-based logic to the Helm reconciler in Go language. Authors can use Go to continue adding new APIs and custom resource definitions (CRDs) in the same project.

For more details, see Operator SDK tutorial for Hybrid Helm Operators.

Operator authors can now use the Ansible-based Operator support in the Operator SDK to expose custom metrics, emit Kubernetes events, and provide better logging.

For more details, see Exposing custom metrics for Ansible-based Operators.

The operator-lib pruning utility lets Go-based Operators clean up objects, such as jobs or pods, that can stay in the cluster and use resources. The utility includes common pruning strategies for Go-based Operators. Operator authors can also use the utility to create custom hooks and strategies.

For more information about the pruning utility, see Object pruning utility for Go-based Operators.

With this enhancement, Operator SDK can now package an Operator project into a bundle that works in a disconnected environment with Operator Lifecycle Manager (OLM). Operator authors can run the make bundle command and set USE_IMAGE_DIGESTS to true to automatically update your Operator image reference to a digest rather than a tag. To use the command, you must use environment variables to replace hard-coded related image references.

For more information about developing Operators for disconnected environments, see Enabling your Operator for restricted network environments.

With this enhancement, you can create a machine set running on Azure that deploys machines on Ephemeral OS disks. Ephemeral OS disks use local VM capacity rather than remote Azure Storage.

For more information, see Machine sets that deploy machines on Ephemeral OS disks.

With this release, you can enable Accelerated Networking for Microsoft Azure VMs by using the Machine API. Accelerated Networking uses single root I/O virtualization (SR-IOV) to provide VMs with a more direct path to the switch.

For more information, see Accelerated Networking for Microsoft Azure VMs.

With this release, you can use availability sets in global Azure regions that do not have multiple availability zones to ensure high availability.

Google Cloud Platform (GCP) Compute Engine enables users to add GPUs to VM instances. Workloads that benefit from access to GPU resources can perform better on compute machines with this feature enabled. With this release, you can define which supported GPU to use for an instance by using the Machine API.

For more information, see Enabling GPU support for a machine set.

With this enhancement, you can specify a node utilization threshold in the ClusterAutoscaler resource definition. This threshold represents the node utilization level below which an unnecessary node is eligible for deletion.

For more information, see About the cluster autoscaler.

With this enhancement, the Machine Config Daemon (MCD) now checks nodes for configuration drift if a filesystem write event occurs for any of the files specified in the machine config and before a new machine config is applied, in addition to node bootup. Previously, the MCD checked for configuration drift only at node bootup. This change was made because node reboots do not occur frequently enough to avoid the problems caused by configuration drift until an administrator can correct the issue.

Configuration drift occurs when the on-disk state of a node differs from what is configured in the machine config. The Machine Config Operator (MCO) uses the MCD to check nodes for configuration drift and, if detected, sets that node and machine config pool (MCP) to degraded.

For more information about configuration drift, see Understanding configuration drift detection.

You can now enable Linux control groups version 2 (cgroups v2) on specific nodes in your cluster. The OpenShift Container Platform process for enabling cgroups v2 disables all cgroups version 1 controllers and hierarchies. The OpenShift Container Platform cgroups version 2 feature is in Developer Preview and is not supported by Red Hat at this time. For more information, see Enabling Linux control groups version 2 (cgroups v2).

You can enable swap memory use for OpenShift Container Platform workloads on a per-node basis. For more information, see Enabling swap memory use on nodes.

The Node Maintenance Operator (NMO) cordons off nodes from the rest of the cluster and drains all the pods from the nodes. By placing nodes under maintenance, you can investigate problems with a machine, or perform operations on the underlying machine, that might result in a node failure. This is a standalone version of NMO. If you installed OpenShift Virtualization, then you must use the NMO that is bundled with it.

The Node Health Check Operator provides these new enhancements:

The Poison Pill Operator uses NodeDeletion as its default remediation strategy. The NodeDeletion remediation strategy removes the node object.

In OpenShift Container Platform 4.10, the Poison Pill Operator introduces a new remediation strategy called ResourceDeletion. The ResourceDeletion remediation strategy removes the pods and associated volume attachments on the node rather than the node object. This strategy helps to recover workloads faster.

You can now migrate control plane nodes from one RHOSP host to another without encountering a service disruption.

Updates to versions of monitoring stack components and dependencies include the following:

A new Metrics Targets page in the OpenShift Container Platform web console shows targets for default OpenShift Container Platform projects and for user-defined projects. You can use this page to view, search, and filter the endpoints that are currently targeted for scraping, which helps you to identify and troubleshoot problems.

With this release, all monitoring components are now configured to use mutual TLS authentication, rather than Bearer Token static authentication for metrics collection. TLS authentication is more resilient to Kubernetes API outages and decreases the load on the Kubernetes API.

With this release, the Cluster Monitoring Operator components now honor the global OpenShift Container Platform tlsSecurityProfile settings. The following components and services now use the TLS security profile:

If you have enabled user-defined monitoring, the following pods now use the profile:

With this release, hard anti-affinity rules and pod disruption budgets have been enabled for the following monitoring components to reduce downtime during patch upgrades:

If you have enabled user-defined monitoring, the following components also use these rules and budgets:

This release introduces a Technology Preview feature in which an administrator can enable alert routing for user-defined projects monitoring. Users can then add and configure alert routing for their user-defined projects.

Access to the third-party Alertmanager web user interface from the OpenShift Container Platform route has been removed.

Access to the third-party Grafana web user interface is deprecated and will be removed in a future OpenShift Container Platform release.

The Special Resource Operator (SRO) now exposes metrics to help you watch the health of your SRO custom resources and objects. For more information, see Prometheus Special Resource Operator metrics.

Using oc explain for Special Resource Operator (SRO) now provides online documentation for SRO custom resource definitions (CRD). This enhancement provides better specifics for CRD fields. (BZ#2031875)

A Node Tuning Operator (NTO) metric is now added to Telemetry. Follow the procedure in Showing data collected by Telemetry to see all the metrics collected by Telemetry.

The Node Feature Discovery (NFD) Topology Updater is a daemon responsible for examining allocated resources on a worker node. It accounts for resources that are available to be allocated to new pod on a per-zone basis, where a zone can be a Non-Uniform Memory Access (NUMA) node. See Using the NFD Topology Updater for more information.

Hyperthreading-aware CPU manager policy in OpenShift Container Platform is now available without the need for extra tuning. The cluster administrator can enable this feature if required. Hyperthreads are abstracted by the hardware as logical processors. Hyperthreading allows a single physical processor to execute two heavyweight threads (processes) at the same time, dynamically sharing processor resources.

The default OpenShift Container Platform scheduler does not see individual non-uniform memory access (NUMA) zones in the compute node. This can lead to sub-optimal scheduling of latency-sensitive workloads. A new NUMA Resources Operator is available which deploys a NUMA-aware secondary scheduler. The NUMA-aware secondary scheduler makes scheduling decisions for workloads based on a complete picture of available NUMA zones in the cluster. This ensures that latency-sensitive workloads are processed in a single NUMA zone for maximum efficiency and performance.

For more information, see About NUMA-aware scheduling.

You can now use filters to customize SiteConfig CRs to include or exclude other CRs for use in the installation phase of the zero touch provisioning (ZTP) GitOps pipeline. For more information, see Filtering custom resources using SiteConfig filters.

On nodes running RAN vDU applications, you must disable chronyd if you update to OpenShift Container Platform 4.10 from earlier versions. To disable chronyd, add the following line in the [service] section under .spec.profile.data of the TunedPerformancePatch.yaml file. The TunedPerformancePatch.yaml file is referenced in the group PolicyGenTemplate CR:

[service]
service.chronyd=stop,disable

For more information, Recommended cluster configurations to run vDU applications.

This release introduces a Technology Preview flag --replica-sets to the oc adm prune deployments command. By default, only replication controllers are pruned with the oc adm prune deployments command. When you set --replica-sets to true, replica sets are also included in the pruning process.

For more information, see Pruning deployment resources.

In OpenShift Container Platform 4.10, Insights Operator now imports your simple content access certificates from Red Hat OpenShift Cluster Manager by default.

For more information, see Importing simple content access certificates with Insights Operator.

To reduce the amount of data sent to Red Hat, Insights Operator only gathers information when certain conditions are met. For example, Insights Operator only gathers the Alertmanager logs when Alertmanager fails to send alert notifications.

In OpenShift Container Platform 4.10, the Insights Operator collects the following additional information:

With this additional information, Red Hat improves OpenShift Container Platform functionality and enhances Insights Advisor recommendations.

This release introduces support for synchronizing group membership from an OpenID Connect provider to OpenShift Container Platform upon user login. You can enable this by configuring the groups claim in the OpenShift Container Platform OpenID Connect identity provider configuration.

For more information, see Sample OpenID Connect CRs.

The Okta and Ping Identity OpenID Connect (OIDC) providers are now tested and supported with OpenShift Container Platform.

For the full list of OIDC providers, see Supported OIDC providers.

Previously, oc commands that used the registry configuration, for example oc registry login or oc image commands, obtained credentials from Docker configuration locations. With OpenShift Container Platform 4.10, if a registry entry cannot be found in the default Docker configuration location, oc commands obtain the credentials from Podman configuration locations. You can set your preference to either docker or podman by using the REGISTRY_AUTH_PREFERENCE environment variable to prioritize the location.

Users also have the option to use the REGISTRY_AUTH_FILE environment variable, which serves as an alternative to the existing --registry-config CLI flag. The REGISTRY_AUTH_FILE environment variable is also compatible with podman.

You can now use the Cloud Credential Operator (CCO) utility ccoctl to configure the CCO to use the Google Cloud Platform Workload Identity. When the CCO is configured to use GCP Workload Identity, the in-cluster components can impersonate IAM service accounts using short-term, limited-privilege security credentials to components.

For more information, see Using manual mode with GCP Workload Identity.

RHCOS functionality in IBM POWER8, IBM z13 all models, LinuxONE Emperor, LinuxONE Rockhopper, and AMD64 (x86_64) v1 CPU architectures will be deprecated in an upcoming release. Additional details for when support will discontinue for these architectures will be announced in a future release.

Previously, oc commands that used a registry configuration would obtain credentials from the Docker configuration location, which was ~/.docker/config.json by default. This has been deprecated and will be replaced by a Podman configuration location in a future version of OpenShift Container Platform.

Support for empty files using the --registry-config and --to flags in oc registry login has been deprecated. Support for - (standard output) has also been deprecated as an argument when using oc registry login. They will be removed in a future version of OpenShift Container Platform.

In OpenShift Container Platform 4.10, the non-sidecar maven and nodejs pod templates for Jenkins are deprecated. These pod templates are planned for removal in a future release. Bug fixes and support are provided through the end of that future life cycle, after which no new feature enhancements are made. Instead, with this update, you can run Jenkins agents as sidecar containers. (JKNS-257)

For the following monitoring stack components, access to third-party web user interfaces (UIs) is deprecated and is planned to be removed in a future OpenShift Container Platform release:

As an alternative, users can navigate to the Observe section of the OpenShift Container Platform web console to access dashboards and other UIs for platform components.

In OpenShift Container Platform 4.10, persistent storage using FlexVolume is deprecated. This feature is still fully supported, but only important bugs will be fixed. However, it may be removed in a future OpenShift Container Platform release. Out-of-tree Container Storage Interface (CSI) driver is the recommended way to write volume drivers in OpenShift Container Platform. Maintainers of FlexVolume drivers should implement a CSI driver and move users of FlexVolume to CSI. Users of FlexVolume should move their workloads to CSI driver.

Support for using Red Hat Enterprise Linux (RHEL) 7 with the OpenShift CLI (oc) is deprecated and will be removed in a future OpenShift Container Platform release.

The following OpenShift CLI (oc) commands were removed with this release:

Support for configuring a scheduler policy has been removed with this release. Use a scheduler profile instead to control how pods are scheduled onto nodes.

Support for running Red Hat Enterprise Linux (RHEL) 7 compute machines in OpenShift Container Platform has been removed. If you prefer using RHEL compute machines, they must run on RHEL 8.

You cannot upgrade RHEL 7 compute machines to RHEL 8. You must deploy new RHEL 8 hosts, and the old RHEL 7 hosts must be removed.

With this release, you can no longer access third-party web user interfaces (UIs) for the following monitoring stack components:

Instead, you can navigate to the Observe section of the OpenShift Container Platform web console to access metrics, alerting, and metrics targets UIs for platform components.

Support for using the Cloud Credential Operator (CCO) in mint mode on Microsoft Azure clusters has been removed. This change is due to the planned retirement of the Azure AD Graph API by Microsoft on 30 June 2022 and is being backported to all supported versions of OpenShift Container Platform in z-stream updates.

For previously installed Azure clusters that use mint mode, the CCO attempts to update existing secrets. If a secret contains the credentials of previously minted app registration service principals, it is updated with the contents of the secret in kube-system/azure-credentials. This behavior is similar to passthrough mode.

For clusters with the credentials mode set to its default value of "", the updated CCO automatically changes from operating in mint mode to operating in passthrough mode. If your cluster has the credentials mode explicitly set to mint mode ("Mint"), you must change the value to "" or "Passthrough".

While the Azure AD Graph API is still available, the CCO in upgraded versions of OpenShift Container Platform attempts to clean up previously minted app registration service principals. Upgrading your cluster before the Azure AD Graph API is retired might avoid the need to clean up resources manually.

If the cluster is upgraded to a version of OpenShift Container Platform that no longer supports mint mode after the Azure AD Graph API is retired, the CCO sets an OrphanedCloudResource condition on the associated CredentialsRequest but does not treat the error as fatal. The condition includes a message similar to unable to clean up App Registration / Service Principal: <app_registration_name>. Cleanup after the Azure AD Graph API is retired requires manual intervention using the Azure CLI tool or the Azure web console to remove any remaining app registration service principals.

To clean up resources manually, you must find and delete the affected resources.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

This update contains changes from Kubernetes 1.23.3 up to 1.23.5. More information can be found in the following changelogs: 1.23.4 and 1.23.5

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

Starting with OpenShift Container Platform 4.10.8, support for Google Cloud Platform Workload Identity has been removed from OpenShift Container Platform 4.10 for the image registry. This change is due to the discovery of an adverse impact to the image registry.

With OpenShift Container Platform 4.10.21, support for using GCP Workload Identity with the image registry is restored. For more information about the status of this feature between OpenShift Container Platform 4.10.8 and 4.10.20, see the related Knowledgebase article.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

The feature change in OpenShift Container Platform 4.10.8 to remove support for Google Cloud Platform (GCP) Workload Identity for the image registry has been resolved in OpenShift Container Platform 4.10.21.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

You can now use the upstream Topology Aware Lifecycle Manager to perform updates on multiple single-node Openshift clusters by using Red Hat Advanced Cluster Management (RHACM) policies. For more information, see About the Topology Aware Lifecycle Manager configuration.

OpenShift Container Platform now provides a hardware event proxy that enables applications running on bare-metal clusters to respond quickly to Redfish hardware events, such as hardware changes and failures.

The hardware event proxy supports a publish-subscribe service that allows relevant applications to consume hardware events detected by Redfish. The proxy must be running on hardware that supports Redfish v1.8 and later. An Operator manages the lifecycle of the hw-event-proxy container.

You can use a REST API to develop applications to consume and respond to events such as breaches of temperature thresholds, fan failure, disk loss, power outages, and memory failure. Reliable end-to-end messaging without persistent stores is based on the Advanced Message Queuing Protocol (AMQP). The latency of the messaging service is in the 10 millisecond range.

Use zero touch provisioning (ZTP) to provision distributed units at new edge sites in a disconnected environment. This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.9 and is now generally available and enabled by default in OpenShift Container Platform 4.11. For more information, see Preparing the hub cluster for ZTP.

A new tool is available that simplifies the process of checking for a completed zero touch provisioning (ZTP) installation using the Red Hat Advanced Cluster Management (RHACM) static validator inform policy. It provides an indication of done for ZTP installations by capturing the criteria for a completed installation and validating that it moves to a compliant state only when ZTP provisioning of the spoke cluster is complete.

This policy can be used for deployments of single node clusters, three-node clusters, and standard clusters. To learn more about the validator inform policy, see Indication of done for ZTP installations.

For OpenShift Container Platform 4.10, there are a number of updates that make it easier to configure the hub cluster and generate source CRs. New PTP and UEFI secure boot features for spoke clusters are also available. The following is a summary of these features:

Zero touch provisioning (ZTP) provides support for multicluster deployment, including single node clusters, three-node clusters, and standard OpenShift clusters. This includes the installation of OpenShift and deployment of the distributed units (DUs) at scale. This gives you the ability to deploy nodes with master, worker, and master and worker roles. ZTP multinode support is implemented through the use of SiteConfig and PolicyGenTemplate custom resources (CRs). The overall flow is identical to the ZTP support for single node clusters, with some differentiation in configuration depending on the type of cluster:

In the SiteConfig file:

The PolicyGenTemplate file tells the Policy Generator where to categorize the generated policies. Example PolicyGenTemplate files provide you with example files to simplify your deployments:

To learn more about multicluster deployment, see Deploying a managed cluster with SiteConfig and ZTP.

This release includes the following warning when enabling TLS for the HTTPD server using the Assisted Installer in IPI or ZTP disconnected environments. When enabling TLS for the HTTPD server in these environments, you must confirm the root certificate is signed by an authority trusted by the client and verify the trusted certificate chain between your OpenShift Container Platform hub and spoke clusters and the HTTPD server. Using a server configured with an untrusted certificate prevents the images from being downloaded to the image creation service. Using untrusted HTTPS servers is not supported.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

For more information, see Configuring bound service account tokens using volume projection.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster within a minor version by using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.10 cluster to this latest release, see Updating a cluster using the CLI for instructions.