Chapter 1. OpenShift Container Platform 4.8 release notes

RHCOS now uses Red Hat Enterprise Linux (RHEL) 8.4 packages in OpenShift Container Platform 4.8, as well as in OpenShift Container Platform 4.7.24 and above. This enables you to have the latest fixes, features, and enhancements, as well as the latest hardware support and driver updates. OpenShift Container Platform 4.6 is an Extended Update Support (EUS) release that will continue to use RHEL 8.2 EUS packages for the entirety of its lifecycle.

Stream metadata provides a standardized JSON format for injecting metadata into the cluster during OpenShift Container Platform installation. For improved automation, the new openshift-install coreos print-stream-json command provides a method for printing stream metadata in a scriptable, machine-readable format.

For user-provisioned installations, the openshift-install binary contains references to the version of RHCOS boot images that are tested for use with OpenShift Container Platform, such as the AWS AMI. You can now parse the stream metadata from a Go program by using the official stream-metadata-go library at https://github.com/coreos/stream-metadata-go.

For more information, see Accessing RHCOS AMIs with stream metadata.

OpenShift Container Platform now includes the Butane config transpiler to assist with producing and validating machine configs. Documentation now recommends using Butane to create machine configs for LUKS disk encryption, boot disk mirroring, and custom kernel modules.

For more information, see Creating machine configs with Butane.

If a cloud administrator has already set a custom /etc/chrony.conf configuration, RHCOS no longer sets the PEERNTP=no option by default on cloud platforms. Otherwise, the PEERNTP=no option is still set by default. See BZ#1924869 for more information.

Enabling multipathing during bare metal installation is now supported for nodes provisioned in OpenShift Container Platform 4.8 or higher. You can enable multipathing by appending kernel arguments to the coreos-installer install command so that the installed system itself uses multipath beginning from the first boot. While post-installation support is still available by activating multipathing via the machine config, enabling multipathing during installation is recommended for nodes provisioned starting in OpenShift Container Platform 4.8.

For more information, see Enabling multipathing with kernel arguments on RHCOS.

You can now define an already existing resource group to install your cluster to on Azure by defining the platform.azure.resourceGroupName field in the install-config.yaml file. This resource group must be empty and only used for a single cluster; the cluster components assume ownership of all resources in the resource group.

If you limit the service principal scope of the installation program to this resource group, you must ensure all other resources used by the installation program in your environment have the necessary permissions, such as the public DNS zone and virtual network. Destroying the cluster using the installation program deletes the user-defined resource group.

You can now define a pre-existing Amazon Web Services (AWS) IAM role for your machine instance profiles by setting the compute.platform.aws.iamRole and controlPlane.platform.aws.iamRole fields in the install-config.yaml file. This allows you to do the following for your IAM roles:

You can now define an existing Route 53 private hosted zone for your cluster by setting the platform.aws.hostedZone field in the install-config.yaml file. You can only use a pre-existing hosted zone when also supplying your own VPC.

The OpenShift Container Platform installation program for Google Cloud Platform (GCP) now creates subnets as large as possible within the machine CIDR. This allows the cluster to use a machine CIDR appropriately sized to accommodate the number of nodes in the cluster.

With this release, the upgrade duration for cluster Operators that deploy daemon sets to all nodes is significantly reduced. For example, the upgrade duration of a 250-node test cluster is reduced from 7.5 hours to 1.5 hours, resulting in upgrade duration scaling of less than one minute per additional node.

When updating, the Machine Config Operator (MCO) now reports an Upgradeable=False condition in the machine-config Cluster Operator if any machine config pool has not completed updating. This status blocks future minor updates, but does not block future patch updates, or the current update. Previously, the MCO reported the Upgradeable status based only on the state of the control plane machine config pool, even if the worker pools were not done updating.

In OpenShift Container Platform 4.8, you can use Fujitsu hardware and the Fujitsu iRMC base board management controller protocol when deploying installer-provisioned clusters on bare metal. Currently Fujitsu supports iRMC S5 firmware version 3.05P and above for installer-provisioned installation on bare metal. Enhancements and bug fixes for OpenShift Container Platform 4.8 include:

You can now deploy clusters on RHOSP that use single-root I/O virtualization (SR-IOV) networks for compute machines.

See Installing a cluster on OpenStack that supports SR-IOV-connected compute machines for more information.

With this update, the Ironic Python Agent now reports VLAN interfaces in the list of interfaces during introspection. Additionally, the IP address is included on the interfaces, which allows for proper creation of a CSR. As a result, a CSR can be obtained for all interfaces, including VLAN interfaces. For more information, see BZ#1888712.

The OpenShift Update Service (OSUS) provides over-the-air updates to OpenShift Container Platform, including Red Hat Enterprise Linux CoreOS (RHCOS). It was previously only accessible as a Red Hat hosted service located behind public APIs, but can now be installed locally. The OpenShift Update Service is composed of an Operator and one or more application instances and is now generally available in OpenShift Container Platform 4.6 and higher.

For more information, see Understanding the OpenShift Update Service.

For console and downloads routes, custom routes functionality is now implemented to use the new ingress config route configuration API spec.componentRoutes. The Console Operator config already contained custom route customization, but for the console route only. The route configuration via console-operator config is being deprecated. Therefore, if the console custom route is set up in both the ingress config and console-operator config, then the new ingress config custom route configuration takes precedent.

For more information, see Customizing console routes.

You can now execute a CLI snippet when it is included in a quick start from the web console. To use this feature, you must first install the Web Terminal Operator. The web terminal and code snippet actions that execute in the web terminal are not present if you do not install the Web Terminal Operator. Alternatively, you can copy a code snippet to the clipboard regardless of whether you have the Web Terminal Operator installed or not.

Previously, quick start prerequisites were displayed as combined text instead of a list on the quick start card. With scalability in mind, the prerequisites are now presented in a popover rather than on the card.

With this release, you can:

The Default audit log policy now logs request bodies for OAuth access token creation (login) and deletion (logout) requests. Previously, deletion request bodies were not logged.

For more information about audit log policies, see Configuring the node audit log policy.

Generating a service serving certificate for headless services now includes a wildcard subject in the format of *.<service.name>.<service.namespace>.svc. This allows for TLS-protected connections to individual stateful set pods without having to manually generate certificates for these pods.

For more information, see Add a service certificate.

The Compliance Operator automates many of the checks and remediations for an OpenShift Container Platform cluster. However, the full process of bringing a cluster into compliance often requires administrator interaction with the Compliance Operator API and other components. The oc-compliance plugin is now available and makes the process easier.

For more information, see Using the oc-compliance plugin

The Kubernetes API server TLS security profile setting is now also honored by the Kubernetes scheduler and Kubernetes controller manager.

For more information, see Configuring TLS security profiles.

You can now set a TLS security profile for kubelet when it acts as an HTTP server for the Kubernetes API server.

For more information, see Configuring TLS security profiles.

Previously, the oauth-proxy command only allowed the use of SHA-1 hashed passwords in htpasswd files used for authentication. oauth-proxy now includes support for htpasswd entries that use bcrypt password hashing. For more information, see BZ#1874322.

OpenShift Container Platform 4.8 supports automatically turning on UEFI Secure Boot mode for provisioned control plane and worker nodes and turning it back off when removing the nodes. To use this feature, set the node’s bootMode configuration setting to UEFISecureBoot in the install-config.yaml file. Red Hat only supports installer-provisioned installation with managed Secure Boot on 10th generation HPE hardware or 13th generation Dell hardware running firmware version 2.75.75.75 or greater. For additional details, see Configuring managed Secure Boot in the install-config.yaml file.

For clusters on installer-provisioned bare metal infrastructure, the OVN-Kubernetes cluster network provider supports both IPv4 and IPv6 address families.

For installer-provisioned bare metal clusters upgrading from previous versions of OpenShift Container Platform, you must convert your cluster to support dual-stack networking. For more information, see Converting to IPv4/IPv6 dual stack networking.

An OpenShift SDN cluster network provider migration to the OVN-Kubernetes cluster network provider is supported for user-provisioned clusters. For more information, see Migrate from the OpenShift SDN cluster network provider.

The egress IP feature of OpenShift SDN now balances network traffic roughly equally across nodes for a given namespace, if that namespace is assigned multiple egress IP addresses. Each IP address must reside on a different node. For more information, refer to Configuring egress IPs for a project for OpenShift SDN.

When using the OpenShift SDN or OVN-Kubernetes cluster network providers, you can select traffic from Ingress Controllers in a network policy rule regardless of whether an Ingress Controller runs on the cluster network or the host network. In a network policy rule, the policy-group.network.openshift.io/ingress: "" namespace selector label matches traffic from an Ingress Controller. You can continue to use the network.openshift.io/policy-group: ingress namespace selector label, but this is a legacy label that can be removed in a future release of OpenShift Container Platform.

In earlier releases of OpenShift Container Platform, the following limitations existed:

For more information, refer to About network policy.

When using either the OVN-Kubernetes cluster network provider or the OpenShift SDN cluster network provider, you can use the policy-group.network.openshift.io/host-network: "" namespace selector to select host network traffic in a network policy rule.

If you use the OVN-Kubernetes cluster network provider, you can enable audit logging for network policies in a namespace. The logs are in a syslog compatible format and can be saved locally, sent over a UDP connection, or directed to a UNIX domain socket. You can specify whether to log allowed, dropped, or both allowed and dropped connections. For more information, see Logging network policy events.

You can create network policies that apply to macvlan additional networks by using the MultiNetworkPolicy API, which implements the NetworkPolicy API. For more information, see Configuring multi-network policy.

OpenShift Container Platform 4.8 adds support for additional Intel and Mellanox network interface controllers.

For more information, see the supported devices.

The Network Resources Injector that is deployed with the Operator is enhanced to expose information about huge pages requests and limits with the Downward API. When a pod specification includes a huge pages request or limit, the information is exposed in the /etc/podnetinfo path.

For more information, see Huge pages resource injection for Downward API.

OpenShift Container Platform 4.8 adds support for sending the metadata about network flows on the pod network to a network flows collector. The following protocols are supported:

Packet data is not sent to the network flows collector. Packet-level metadata such as the protocol, source address, destination address, port numbers, number of bytes, and other packet-level information is sent to the network flows collector.

For more information, see Tracking network flows.

OpenShift Container Platform 4.8 and later releases include functionality that uses cluster membership information to generate A/AAAA records. This resolves the node names to their IP addresses. Once the nodes are registered with the API, the cluster can disperse node information without using CoreDNS-mDNS. This eliminates the network traffic associated with multicast DNS.

OpenShift Container Platform updated to HAProxy 2.2, which changes HTTP header names to lowercase by default, for example, changing Host: xyz.com to host: xyz.com. For legacy applications that are sensitive to the capitalization of HTTP header names, use the Ingress Controller spec.httpHeaders.headerNameCaseAdjustments API field to accommodate legacy applications until they can be fixed. Make sure to add the necessary configuration by using spec.httpHeaders.headerNameCaseAdjustments before upgrading OpenShift Container Platform now that HAProxy 2.2 is available.

For more information, see Converting HTTP header case.

OpenShift Container Platform updated to HAProxy 2.2, which enforces some additional restrictions on HTTP headers. These restrictions are intended to mitigate possible security weaknesses in applications. In particular, HTTP client requests that specify a host name in an HTTP request line may be rejected if the request line and HTTP host header in a request do not both either specify or omit the port number. For example, a request GET http://hostname:80/path with the header host: hostname will be rejected with an HTTP 400 "Bad request" response because the request line specifies a port number while the host header does not. The purpose of this restriction is to mitigate request smuggling attacks.

This stricter HTTP header validation was also enabled in previous versions of OpenShift Container Platform when HTTP/2 was enabled. This means that you can test for problematic client requests by enabling HTTP/2 on a OpenShift Container Platform 4.7 cluster and checking for HTTP 400 errors. For information on how to enable HTTP/2, see Enabling HTTP/2 Ingress connectivity.

OpenShift Container Platform 4.8 adds support for the global access option for Ingress Controllers created on GCP with an internal load balancer. When the global access option is enabled, clients in any region within the same VPC network and compute region as the load balancer can reach the workloads running on your cluster.

For more information, see Configuring global access for an Ingress Controller on GCP.

OpenShift Container Platform 4.8 adds support for setting the thread count to increase the amount of incoming connections a cluster can handle.

For more information, see Setting Ingress Controller thread count.

OpenShift Container Platform 4.8 adds support for configuring the PROXY protocol for the Ingress Controller on non-cloud platforms, specifically for HostNetwork or NodePortService endpoint publishing strategy types.

For more information, see Configuring PROXY protocol for an Ingress Controller.

In OpenShift Container Platform 4.8, installer-provisioned clusters can configure and deploy Network Time Protocol (NTP) servers on the control plane nodes and NTP clients on worker nodes. This enables workers to retrieve the date and time from the NTP servers on the control plane nodes, even when disconnected from a routable network. You can also configure and deploy NTP servers and NTP clients after deployment.

In OpenShift Container Platform 4.8 deployments on Red Hat OpenStack Platform (RHOSP) with Kuryr-Kubernetes, the API load balancer for the default/kubernetes service is no longer managed by the Cluster Network Operator (CNO), but instead by the kuryr-controller itself. This means that:

The assisted installer and installer-provisioned installation for bare metal clusters provide the ability to deploy a cluster without a provisioning network. In OpenShift Container Platform 4.8 and later, you can enable a provisioning network after installation by using the Cluster Baremetal Operator (CBO).

If you need the virtual IP (VIP) addresses to run on the control plane nodes in a bare metal installation, you must configure the apiVIP and ingressVIP VIP addresses to run exclusively on the control plane nodes. By default, OpenShift Container Platform allows any node in the worker machine configuration pool to host the apiVIP and ingressVIP VIP addresses. Because many bare metal environments deploy worker nodes in separate subnets from the control plane nodes, configuring the apiVIP and ingressVIP virtual IP addresses to run exclusively on the control plane nodes prevents issues from arising due to deploying worker nodes in separate subnets. For additional details, see Configure network components to run on the control plane.

In OpenShift Container Platform 4.8, you can configure an external load balancer to handle apiVIP and ingressVIP traffic for Red Hat OpenStack Platform (RHOSP) and bare-metal installer-provisioned clusters. External load balancing services and the control plane nodes must run on the same L2 network, and on the same VLAN when using VLANs to route traffic between the load balancing services and the control plane nodes.

Configuring load balancers to handle apiVIP and ingressVIP traffic is not supported for VMware installer-provisioned clusters.

OpenShift Container Platform 4.8 adds OVN-Kubernetes IPsec support for clusters that are configured to use dual-stack networking.

The egress router CNI plugin is generally available. The Cluster Network Operator is enhanced to support an EgressRouter API object. The process for adding an egress router on a cluster that uses OVN-Kubernetes is simplified. When you create an egress router object, the Operator automatically adds a network attachment definition and a deployment. The pod for the deployment acts as the egress router.

For more information, see Considerations for the use of an egress router pod.

IP failover is now supported on OpenShift Container Platform clusters on bare metal. IP failover uses keepalived to host a set of externally accessible VIP addresses on a set of hosts. Each VIP is only serviced by a single host at a time. keepalived uses the Virtual Router Redundancy Protocol (VRRP) to determine which host, from the set of hosts, services which VIP. If a host becomes unavailable, or if the service that keepalived is watching does not respond, the VIP is switched to another host from the set. This means a VIP is always serviced as long as a host is available.

For more information, see Configuring IP failover.

In OpenShift Container Platform 4.8, you can use a custom node selector and tolerations to configure the daemon set for CoreDNS to run or not run on certain nodes.

For more information, see Controlling DNS pod placement.

OpenShift Container Platform clusters on Red Hat OpenStack Platform (RHOSP) now support provider networks for all deployment types.

Cluster Administrators can now set headerBufferMaxRewriteByte and headerBufferBytes Ingress Controller tuning parameters to configure tune.maxrewrite and tune.bufsize HAProxy memory options per-Ingress Controller.

See Ingress Controller configuration parameters for more information.

The Google Cloud Platform (GCP) persistent disk (PD) Container Storage Interface (CSI) driver is automatically deployed and managed on GCP environments, allowing you to dynamically provision these volumes without having to install the driver manually. This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.7 and is now generally available and enabled by default in OpenShift Container Platform 4.8.

For more information, GCP PD CSI Driver Operator.

The Azure Disk CSI Driver Operator provides a storage class by default that you can use to create persistent volume claims (PVCs). The Azure Disk CSI Driver Operator that manages this driver is in Technology Preview.

For more information, see Azure Disk CSI Driver Operator.

The vSphere CSI Driver Operator provides a storage class by default that you can use to create persistent volume claims (PVCs). The vSphere CSI Driver Operator that manages this driver is in Technology Preview.

For more information, see vSphere CSI Driver Operator.

Starting with OpenShift Container Platform 4.8, automatic migration for the following in-tree volume plugins to their equivalent CSI drivers is available as a Technology Preview feature:

For more information, see Automatic CSI Migration.

The Amazon Web Services (AWS) Elastic File System (EFS) Technology Preview feature has been removed and is no longer supported.

You can now select availability zones for Cinder volumes during installation. You can also use Cinder volumes in particular availability zones for your image registry.

A cluster administrator using Operator Lifecycle Manager (OLM) to install an Operator can encounter error conditions that are related either to the current API or low-level APIs. Previously, there was little insight into why OLM could not fulfill a request to install or update an Operator. These errors could range from trivial issues like typos in object properties or missing RBAC, to more complex issues where items could not be loaded from the catalog due to metadata parsing.

Because administrators should not require understanding of the interaction process between the various low-level APIs or access to the OLM pod logs to successfully debug such issues, OpenShift Container Platform 4.8 introduces the following enhancements in OLM to provide administrators with more comprehensible error reporting and messages:

Install plans, defined by an InstallPlan object, can encounter transient errors, for example, due to API server availability or conflicts with other writers. Previously, these errors would result in the termination of partially-applied install plans that required manual cleanup. With this enhancement, the Catalog Operator now retries errors during install plan execution for up to one minute. The new .status.message field provides a human-readable indication when retries are occurring.

Creating a subscription in a namespace with no Operator groups or multiple Operator groups would previously result in a stalled Operator installation with an install plan that stays in phase=Installing forever. With this enhancement, the install plan immediately transitions to phase=Failed so that the administrator can correct the invalid Operator group, and then delete and re-create the subscription again.

ResolutionFailed events, which are created when dependency resolution in a namespace fails, now provide more specific text when the namespace contains a subscription that references a package or channel that does not exist in the referenced catalog source. Previously, this message was generic:

no candidate operators found matching the spec of subscription '<name>'

With this enhancement, the messages are more specific:

no operators found in package <name> in the catalog referenced by subscription <name>

no operators found from catalog <name> in namespace openshift-marketplace referenced by subscription <name>

no operators found in channel <name> of package <name> in the catalog referenced by subscription <name>

no operators found with name <name>.<version> in channel <name> of package <name> in the catalog referenced by subscription <name>

Support for the legacy package manifest format for Operators is removed in OpenShift Container Platform 4.8 and later. The bundle format is the preferred Operator packaging format for Operator Lifecycle Manager (OLM) starting in OpenShift Container Platform 4.6. If you have an Operator project that was initially created in the package manifest format, which has been deprecated, you can now use the Operator SDK pkgman-to-bundle command to migrate the project to the bundle format.

For more information, see Migrating package manifest projects to bundle format.

To install and manage Operators, Operator Lifecycle Manager (OLM) requires that Operator bundles are listed in an index image, which is referenced by a catalog on the cluster. As an Operator author, you can use the Operator SDK to create an index containing the bundle for your Operator and all of its dependencies. This is useful for testing on remote clusters and publishing to container registries.

For more information, see Publishing a catalog containing a bundled Operator.

The Operator SDK’s run bundle-upgrade subcommand automates triggering an installed Operator to upgrade to a later version by specifying a bundle image for the later version. Previously, the subcommand could only upgrade Operators that were initially installed using the run bundle subcommand. With this enhancement, the run bundle-upgrade now also works with Operators that were initially installed with the traditional Operator Lifecycle Manager (OLM) workflow.

For more information, see Testing an Operator upgrade on Operator Lifecycle Manager.

When an API is removed from an OpenShift Container Platform version, Operators running on that cluster version that are still using removed APIs will no longer work properly. As an Operator author, you should plan to update your Operator projects to accommodate API deprecation and removal to avoid interruptions for users of your Operator.

For more details, see Controlling Operator compatibility with OpenShift Container Platform versions.

Builds

Telemetry includes a new openshift:build_by_strategy:sum gauge metric, which sends the number of builds by strategy type to the Telemeter Client. This metric gives site reliability engineers (SREs) and product managers visibility into the kinds of builds that run on OpenShift Container Platform clusters.

Previously, builds could not use the cluster PKI certificate authorities that were sometimes required to access corporate artifact repositories. Now, you can configure the BuildConfig object to mount cluster custom PKI certificate authorities by setting mountTrustedCA to true.

When running machines in vSphere, you can now set the minReplicas value to 0 in the MachineAutoscaler resource definition. When this value is set to 0, the cluster autoscaler scales the machine set to and from zero depending on if the machines are in use. For more information, see the MachineAutoscaler resource definition.

The automatic rotation of the /etc/kubernetes/kubelet-ca.crt certificate authority (CA) no longer requires the Machine Config Operator (MCO) to drain nodes or reboot the cluster.

As part of this change, the following modifications do not require the MCO to drain nodes:

When the MCO detects any of these changes, it applies the changes and uncordons the node.

For more information, see Understanding the Machine Config Operator.

Previously, creating machine sets required users to manually configure their CPU pinning settings, NUMA pinning settings, and CPU topology changes to get better performance from the host. With this enhancement, users can select a policy in the MachineSet resource to populate settings automatically. For more information, see BZ#1941334.

Providing a hugepages property into the MachineSet resource is now possible. This enhancement creates the MachineSet resource’s nodes with a custom property in oVirt and instructs those nodes to use the hugepages of the hypervisor. For more information, see BZ#1948963.

OpenShift Container Platform 4.8 avoids workload disruption for selected ImageContentSourcePolicy object changes. This feature helps users and teams add additional mirrors and registries without workload disruption. As a result, workload distruption will no longer occur for the following changes in /etc/containers/registries.conf files:

For any other changes in /etc/containers/registries.conf files, the Machine Config Operator will default to draining nodes to apply changes. For more information, see BZ#1943315.

The operator.openshift.io/v1 API group is now available for the descheduler. Support for the operator.openshift.io/v1beta1 API group for the descheduler might be removed in a future release.

You can now enable Prometheus metrics for the descheduler by adding the openshift.io/cluster-monitoring=true label to the openshift-kube-descheduler-operator namespace where you installed the descheduler.

The following descheduler metrics are available:

With this release, when you set requests and limits for huge pages in a pod specification, you can use the Downward API to view the allocation for the pod from within a container. This enhancements relies on the DownwardAPIHugePages feature gate. OpenShift Container Platform 4.8 enables the feature gate.

For more information, see Consuming huge pages resources using the Downward API.

The Node Feature Discovery (NFD) Operator detects hardware features available on each node in an OpenShift Container Platform cluster. Then, it modifies node objects with node labels. This enables the NFD Operator to advertise the features of specific nodes. OpenShift Container Platform 4.8 supports three additional labels for the NFD Operator.

You can use the Poison Pill Operator to allow unhealthy nodes to reboot automatically. This minimizes downtime for stateful applications and ReadWriteOnce (RWO) volumes, and restores compute capacity if transient failures occur.

The Poison Pill Operator works with all cluster and hardware types.

For more information, see Remediating nodes with the Poison Pill Operator.

The automatic rotation of the /etc/kubernetes/kubelet-ca.crt certificate authority (CA) no longer requires the Machine Config Operator (MCO) to drain nodes or reboot the cluster.

As part of this change, the following modifications do not require the MCO to drain nodes:

When the MCO detects any of these changes, it applies the changes and uncordons the node.

For more information, see Understanding the Machine Config Operator.

The OpenShift Container Platform vertical pod autoscaler (VPA) is now generally available. The VPA automatically reviews the historic and current CPU and memory resources for containers in pods and can update the resource limits and requests based on the usage values it learns.

You can also use the VPA with pods that require only one replica by modifying the VerticalPodAutoscalerController object as described below. Previously, the VPA worked only with pods that required two or more replicas.

For more information, see Automatically adjust pod resource levels with the vertical pod autoscaler.

By default, workload objects must specify a minimum of two replicas in order for the VPA to automatically update pods. As a result, workload objects that specify fewer than two replicas are not acted upon by the VPA. You can change this cluster-wide minimum value by modifying the VerticalPodAutoscalerController object to add the minReplicas parameter.

For more information, see Automatically adjust pod resource levels with the vertical pod autoscaler.

OpenShift Container Platform can automatically determine the optimal sizing value of the system-reserved setting when a node starts. Previously, the CPU and memory allocations in the system-reserved setting were fixed limits that you needed to manually determine and set.

When automatic resource allocation is enabled, a script on each node calculates the optimal values for the respective reserved resources based on the installed CPU and memory capacity on the node.

For more information, see Automatically allocating resources for nodes.

You can now specify an individual repository within a registry when creating lists of allowed and blocked registries for pulling and pushing images. Previously, you could specify only a registry.

For more information, see Adding specific registries and Blocking specific registries.

The cron job custom resource is now generally available. As part of this change, a new controller has been implemented that substantially improves the performance of cron jobs. For more information on cron jobs, see Understanding jobs and cron jobs.

OpenShift Container Platform 4.8 includes the following alerting rule changes:

OpenShift Container Platform 4.8 introduces two new alerts that fire when an API that will be removed in the next release is in use:

You can use the new APIRequestCount API to track what is using the deprecated APIs. This allows you to plan whether any actions are required in order to upgrade to the next release.

OpenShift Container Platform 4.8 includes version updates to the following monitoring stack components and dependencies:

kube-state-metrics is upgraded to version 2.0.0. The following metrics were deprecated in kube-state-metrics version 1.9 and are effectively removed in version 2.0.0:

The link to the third-party Alertmanager UI is removed from the Monitoring Alerting page in the OpenShift Container Platform web console. Additionally, the link to the third-party Grafana UI is removed from the Monitoring Dashboards page. You can still access the routes to the Grafana and Alertmanager UIs in the web console in the Administrator perspective by navigating to the Networking Routes page in the openshift-monitoring project.

New enhancements are available on the Monitoring Dashboards page in the OpenShift Container Platform web console:

Running tests on a single node cluster causes longer timeouts for certain tests, including SR-IOV and SCTP tests, and tests requiring control plane and worker nodes are skipped. Reconfiguration requiring node reboots causes a reboot of the entire environment, including the OpenShift control plane, and therefore takes longer to complete. All PTP tests requiring a control plane node and a worker node are skipped. No additional configuration is needed because the tests check for the number of nodes at startup and adjust test behavior accordingly.

PTP tests can run in Discovery mode. The tests look for a PTP control plane configured outside of the cluster. The following parameters are required:

The Performance Addon Operator allows you to adjust the Network Interface Card (NIC) queue count for each network device by configuring the performance profile. Device network queues allow packets to be distributed among different physical queues, and each queue gets a separate thread for packet processing.

For Data Plane Development Kit (DPDK) based workloads, it is important to reduce the NIC queues to only the number of reserved or housekeeping CPUs to ensure the desired low latency is achieved.

For more information, see Reducing NIC queues using the Performance Addon Operator.

Updated guidance around cluster maximums for OpenShift Container Platform 4.8 is now available.

Use the OpenShift Container Platform Limit Calculator to estimate cluster limits for your environment.

You can now create a performance profile using the Performance Profile Creator (PPC) tool. The tool consumes must-gather data from the cluster and several user-supplied profile arguments, and using this information it generates a performance profile that is appropriate for your hardware and topology.

For more information, see Creating a Performance Profile.

The Node Feature Discovery (NFD) Operator is now available. Use it to expose node-level information by orchestrating Node Feature Discovery, a Kubernetes add-on for detecting hardware features and system configuration.

You can now use the Driver Toolkit as a base image for driver containers so that you can enable special software and hardware devices on Kubernetes. This is currently a Technology Preview feature.

A new enhancement validates the status of the etcd snapshot after backup and before restore. Previously, the backup process did not validate that the snapshot taken was complete, and the restore process did not verify that the snapshot being restored was valid, not corrupted. Now, if the disk is corrupted during backup or restore, the error is clearly reported to the admin. For more information, see BZ#1965024.

In OpenShift Container Platform 4.8, users operating in restricted networks can gather and upload Insights Operator archives to Insights Advisor to diagnose potential issues. Additionally, users can obfuscate sensitive data contained in the Insights Operator archive before upload.

For more information, see Using remote health reporting in a restricted network.

Insights Advisor in the OpenShift Container Platform web console now correctly reports 0 issues found. Previously, Insights Advisor gave no information.

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

With this additional information, Red Hat can provide improved remediation steps in Insights Advisor.

The Insights Operator can now gather data for unhealthy SAP pods. When the SDI installation fails, it is possible to detect the problem by looking at which of the initialization pods have failed. The Insights Operator now gathers information about failed pods in the SAP/SDI namespaces. For more information, see BZ#1930393.

The Insights Operator can now gather Datahubs resources from SAP clusters. This data allows SAP clusters to be distinguished from non-SAP clusters in the Insights Operator archives, even in situations in which all of the data gathered exclusively from SAP clusters is missing and it would otherwise be impossible to determine if a cluster has an SDI installation. For more information, see BZ#1940432.

You can now use the Cloud Credential Operator (CCO) utility (ccoctl) to configure the CCO to use the Amazon Web Services Security Token Service (AWS STS). When the CCO is configured to use STS, it assigns IAM roles that provide short-term, limited-privilege security credentials to components.

This feature was previously introduced as a Technology Preview feature in OpenShift Container Platform 4.7, and is now generally available in OpenShift Container Platform 4.8.

For more information, see Using manual mode with STS.

To review OpenShift sandboxed containers new features, bug fixes, known issues, and asynchronous errata updates, see OpenShift sandboxed containers 1.0 release notes.

The operator.openshift.io/v1beta1 API group for the descheduler is deprecated and might be removed in a future release. Use the operator.openshift.io/v1 API group instead.

Starting with OpenShift Container Platform 4.6, Red Hat Enterprise Linux CoreOS (RHCOS) switched to using NetworkManager in the initramfs to configure networking during early boot. As part of this change, the use of the dhclient binary for DHCP was deprecated. Use the NetworkManager internal DHCP client for networking configuration instead. The dhclient binary will be removed from Red Hat Enterprise Linux CoreOS (RHCOS) in a future release. See BZ#1908462 for more information.

Cluster Loader is now deprecated and will be removed in a future release.

This release deprecates the lastTriggeredImageID in the ImageChangeTrigger object, which is one of the BuildTriggerPolicy types that can be set on a BuildConfig spec.

OpenShift Container Platform next release will remove support for lastTriggeredImageID and ignore it. Then, image change triggers will not start a build based on changes to the lastTriggeredImageID field in the BuildConfig spec. Instead, the image IDs that trigger a build will be recorded in the status of the BuildConfig object, which most users cannot change.

Therefore, update scripts and jobs that inspect buildConfig.spec.triggers[i].imageChange.lastTriggeredImageID accordingly. (BUILD-213)

This release deprecates the Jenkins Operator, which was a Technology Preview feature. A future version of OpenShift Container Platform will remove the Jenkins Operator from OperatorHub in the OpenShift Container Platform web console interface. Then, upgrades for the Jenkins Operator will no longer be available, and the Operator will not be supported.

Customers can continue to deploy Jenkins on OpenShift Container Platform using the templates provided by the Samples Operator.

The instance_type_id installation configuration parameter is deprecated and will be removed in a future release.

Starting with OpenShift Container Platform 4.8.34, support for using the Cloud Credential Operator (CCO) in mint mode on Microsoft Azure clusters has been removed from OpenShift Container Platform 4.8. 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.

The following images are no longer included in the samples imagestreams provided with OpenShift Container Platform:

registry.redhat.io/rhscl/nodejs-10-rhel7
registry.redhat.io/ubi7/nodejs-10
registry.redhat.io/rhscl/perl-526-rhel7
registry.redhat.io/rhscl/postgresql-10-rhel7
registry.redhat.io/rhscl/ruby-25-rhel7
registry.redhat.io/ubi7/ruby-25
registry.redhat.io/rhdm-7/rhdm-decisioncentral-rhel8:7.9.0
registry.redhat.io/rhdm-7/rhdm-kieserver-rhel8:7.9.0
registry.redhat.io/rhpam-7/rhpam-businesscentral-monitoring-rhel8:7.9.0
registry.redhat.io/rhpam-7/rhpam-businesscentral-rhel8:7.9.0
registry.redhat.io/rhpam-7/rhpam-smartrouter-rhel8:7.9.0

Support for the legacy package manifest format for Operators is removed in OpenShift Container Platform 4.8 and later. This removal of support includes custom catalogs that were built with the legacy format and Operator projects initially created in the legacy format with the Operator SDK. The bundle format is the preferred Operator packaging format for Operator Lifecycle Manager (OLM) starting in OpenShift Container Platform 4.6.

For more information about working with the bundle format, see Managing custom catalogs and Migrating package manifest projects to bundle format.

In addition, the following commands related to the format have been removed from OpenShift CLI (oc) and the Operator SDK CLI:

This release removes the Prometheus Adapter, which was a Technology Preview feature.

The authentication and openshift-apiserver Operators now ignore the oauth-apiserver.openshift.io/secure-token-storage annotation when picking the audit policy of a cluster. Audit policies now use secure- by default. For more information, see BZ#1879182.

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

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

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

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

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

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

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

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

OpenShift Container Platform 4.8.14 introduces a check that impacts upgrading to the next OpenShift Container Platform release, which is currently planned to be OpenShift Container Platform 4.9. This is because Kubernetes 1.22, which OpenShift Container Platform 4.9 is expected to use, removed a significant number of deprecated v1beta1 APIs.

This check requires an administrator to provide a manual acknowledgment before the cluster can be upgraded from OpenShift Container Platform 4.8 to 4.9. This is to help prevent issues after upgrading to OpenShift Container Platform 4.9, where APIs that have been removed are still in use by the cluster. Administrators must evaluate their cluster for any removed APIs in use and migrate them to use the appropriate new API version. After this evaluation and migration is complete, the administrator can provide the acknowledgment.

All clusters require this administrator acknowledgment before they can be upgraded to OpenShift Container Platform 4.9.

For more information on the list of removed Kubernetes APIs, tips for how to evaluate your cluster for removed APIs in use, and how to provide the administrator acknowledgment, see Preparing to upgrade to OpenShift Container Platform 4.9.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Starting with OpenShift Container Platform 4.8.34, support for using the Cloud Credential Operator (CCO) in mint mode on Microsoft Azure clusters has been removed from OpenShift Container Platform 4.8. 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 more information, see Support for minting credentials for Microsoft Azure removed.

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

To update an existing OpenShift Container Platform 4.8 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.8 cluster to this latest release, see Updating a cluster using the CLI for instructions.

To update an existing OpenShift Container Platform 4.8 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.8 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.8 cluster to this latest release, see Updating a cluster using the CLI for instructions.

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

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

To update an existing OpenShift Container Platform 4.8 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.8 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.8 cluster to this latest release, see Updating a cluster using the CLI for instructions.

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

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

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

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

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

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

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

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

This update contains changes from Kubernetes 1.21.12 up to 1.21.14. More information can be found in the following changelogs: 1.21.12, 1.21.13, and 1.21.14.

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

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

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