Chapter 1. OpenShift Container Platform 4.11 release notes

OpenShift Container Platform 4.11 introduces the

nvme-cli

RHCOS now supports

kdump

x86_64

kdump

RHCOS now supports

kdump

arm64

RHCOS now uses Red Hat Enterprise Linux (RHEL) 8.6 packages in OpenShift Container Platform 4.11 and above. This enables you to have the latest fixes, features, and enhancements, as well as the latest hardware support and driver updates.

The redirector hostname for downloading RHCOS boot images is now

rhcos.mirror.openshift.com

Using Red Hat Enterprise Linux (RHEL) 9 with the OpenShift installer (openshift-install) is now supported.

For more information, see the "Obtaining the installation program" section of the installation documentation for your platform.

This release updates the minimum system requirements for installing OpenShift Container Platform on a single node. When installing OpenShift Container Platform on a single node, you should configure a minimum of 16 GB of RAM. Specific workload requirements can require additional RAM. The complete list of supported platforms has been updated to include bare metal, vSphere, Red Hat OpenStack Platform (RHOSP), and Red Hat Virtualization platforms. In all cases, you must specify the

platform.none: {}

install-config.yaml

openshift-installer

OpenShift Container Platform 4.11 is now supported on ARM architecture based AWS user-provisioned infrastructure and bare-metal installer-provisioned infrastructure. For more information about instance availability and installation documentation, see 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:

The installation program now gathers serial console logs from the bootstrap and control plane hosts on AWS. This log data is added to the standard bootstrap log bundle.

For more information, see Troubleshooting installation issues.

By default, the installation program now deploys a Microsoft Azure cluster using Hyper-V generation version 2 virtual machines (VMs). If the installation program detects that the instance type selected for the VMs does not support version 2, it uses version 1 for the deployment.

Beginning with OpenShift Container Platform 4.11, by default, the installation program now deploys AWS and VMware vSphere compute nodes with 4 vCPUs and 16 GB of virtual RAM.

OpenShift Container Platform 4.11 introduces support for the AWS Secret Commercial Cloud Services (SC2S) region. You can now install and update OpenShift Container Platform clusters in the

us-isob-east-1

For more information, see Installing a cluster on AWS into a Secret or Top Secret Region

OpenShift Container Platform 4.11 introduces support for installing a cluster on Nutanix 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 Nutanix.

You can now enable Ultra SSD storage when installing OpenShift Container Platform on Azure. This feature requires that both the Azure region and zone where you install OpenShift Container Platform offer Ultra storage.

For more information, see Additional Azure configuration parameters.

When deploying an installer-provisioned OpenShift Container Platform cluster on bare metal with static IP addresses and no DHCP server on the

baremetal

bootstrapExternalStaticIP

bootstrapExternalStaticGateway

install-config.yaml

For more information, see Configuring the install-config.yaml file and Additional install-config parameters.

OpenShift Container Platform 4.11 introduces support for configuring the BIOS and RAID arrays of control plane nodes when installing OpenShift Container Platform on bare metal with Fujitsu hardware. In OpenShift Container Platform 4.10, configuring the BIOS and RAID arrays on Fujitsu hardware was limited to worker nodes.

For more information, see Configuring the BIOS and Configuring the RAID.

You can use the oc-mirror OpenShift CLI (

oc

This release of the oc-mirror plugin includes the following new features:

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

OpenShift Container Platform 4.11 introduces support for installing a cluster on Azure with user-managed disk encryption.

For more information, see Enabling user-managed encryption for Azure.

OpenShift Container Platform 4.11 on Azure provides accelerated networking for control plane and compute nodes. Accelerated networking is enabled by default for supported instance types in an installer-provisioned infrastructure installation.

For more information, see Openshift 4 on Azure - accelerated networking.

You are no longer required to configure AWS VPC endpoints when installing a restricted OpenShift Container Platform cluster on AWS. While configuring VPC endpoints remains an option, you can also choose to configure a proxy without VPC endpoints or configure a proxy with VPC endpoints.

For more information, see Requirements for using your VPC.

OpenShift Container Platform 4.11 allows you to disable the installation of the

baremetal

marketplace

openshift-samples

openshift

baselineCapabilitySet

additionalEnabledCapabilities

install-config.yaml

For more information, see the "Installation configuration parameters" section of the installation documentation for your platform.

OpenShift Container Platform is now available on the Azure Marketplace. The Azure Marketplace offering is available to customers who procure OpenShift Container Platform in North America and EMEA.

For more information, see Installing OpenShift using Azure Marketplace.

OpenShift Container Platform is now available on the AWS Marketplace. The AWS Marketplace offering is available to customers who procure OpenShift Container Platform in North America.

For more information, see Installing OpenShift using AWS Marketplace.

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 deprecated or removed. Deprecated versions are still fully supported, but Red Hat recommends that you use ESXi 7.0 Update 2 or later and vSphere 7.0 Update 2 up to but not including version 8. vSphere 8 is not supported.

For more information, see Deprecated and removed features.

As a cluster administrator, you can enable cluster capabilities to select or deselect one or more optional components before installation or post installation.

For more information, see Cluster capabilities.

OpenShift Container Platform 4.11 introduces clusters with multi-architecture compute machines support using Azure installer-provisioned infrastructure in Technology Preview. This feature offers, as a day-two operation, the ability to add

arm64

x86_64

arm64

arm64

arm64

image-pullsec

With this update, you can use the new

console.openshift.io/use-i18next

ConsolePlugin

"true"

ConsolePlugin

For more information, see Overview of dynamic plugins.

The OpenShift Container Platform web console now supports the dark mode theme. On the User Preferences page, select your preferred theme to view the web console in.

With this update, the Operator Installed Operator page will show all Operators across all namespaces. You are still able to view only the instances in the selected namespace within the project selector. When viewing the operand instances, a new switching control allows all operand instances from either all namespaces or only the current namespace to be seen.

With this update, if conditional updates are available, you can enable

Include supported but not recommended versions

Select new version

Supported but not recommended

This update provides support for pod disruption budgets (PDBs) to the OpenShift Container Platform web console. From Workloads PodDisruptionBudgets, you can create PDBs for pod resources. You can select

maxUnavailable

minAvailable

pod controller resources

Add PodDisruptionBudget

For more information, see Pod preemption and other scheduler settings.

Using Red Hat Enterprise Linux (RHEL) 9 with the OpenShift CLI (

oc

oc

For more information, see Installing the OpenShift CLI.

OAuth server audit events, annotated with login events, are now logged at the metadata level in the audit logs. The login events include failed login attempts.

For more information, see About audit log policy profiles.

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.

For more information, see Configuring a bond interface from two SR-IOV interfaces

This update introduces a new option for Ingress Controllers with the

hostnetwork

httpPort

httpsPort

statsPort

You can simultaneously apply a single configuration to multiple, bare-metal, installer-provisioned infrastructure nodes in a cluster. Applying a single configuration to multiple nodes reduces the risk of misconfiguration due to the single-provisioning process.

This mechanism is only available for initial deployments when the

install-config

You can now configure idle connection timeouts for AWS Classic Load Balancers (CLBs) in the Ingress Controller.

For more information, see Configuring Classic Load Balancer timeouts

OpenShift Container Platform updated to HAProxy 2.2.24.

You can now set the maximum number of simultaneous connections that can be established per HAProxy process in the Ingress Controller to any value between 2000 and 2,000,000.

For more information, see Ingress Controller configuration parameters.

With this update, a cluster administrator can set the health check interval to define how long the router waits between two consecutive health checks. This value is applied globally as a default for all routes. The default value is 5 seconds.

For more information, see Ingress Controller configuration parameters.

Use the new

tuning-cni

accept_redirects

tuning-cni

In addition to this enhancement the set of system-wide safe sysctls that can be set has increased to support

net.ipv4.ping_group_range

net.ipv4.ip_unprivileged_port_start

For more information about configuring the

tuning-cni

For more information about the newly supported interface level network safe sysclts and updates to the list of supported system-wide safe sysclts, see Using sysctls in containers.

When working in a highly regulated environment, you might need the ability to secure domain name system (DNS) traffic when forwarding requests to upstream resolvers so that you can ensure additional DNS traffic and data privacy. Cluster administrators can now configure transport layer security (TLS) for forwarded DNS queries. This feature applies only to the DNS Operator and not the CoreDNS instance managed by the Machine Config Operator.

For more information, see Using DNS forwarding.

As a cluster administrator, you can configure

internalTrafficPolicy=Local

For more information, see Service Internal Traffic Policy.

As a cluster administrator, you can install the AWS Load Balancer Operator from the OperatorHub by using the OpenShift Container Platform web console or CLI. The AWS Load Balancer Operator is in Technology Preview.

For more information, see Installing AWS Load Balancer Operator.

Previously, you could not specify the subdomain of a route, and the

spec.host

spec.subdomain

spec.host

spec.subdomain

You can use this enhancement to simplify sharding by enabling a route to have multiple, distinct host names determined by each router deployment that exposes the route.

In OpenShift Container Platform 4.11, the External DNS Operator is available for AWS Route53, Azure DNS, GCP DNS, and Infoblox in General Availability (GA) status. The External DNS Operator is still in Technology Preview (TP) status for BlueCat and AWS Route53 on GovCloud. With this update, the External DNS Operator provides the following enhancements:

Ensure that you migrate from TP to GA. The upstream version of

ExternalDNS

v0.12.0

v0.10.2

You can now configure dual network interfaces (NICs) as boundary clocks with

PtpConfig

For more information, see Using PTP with dual NIC hardware.

A new PTP events API endpoint is available,

api/cloudNotifications/v1/publishers

os-clock-sync-state

ptp-clock-class-change

lock-state

For more information, see Subscribing DU applications to PTP events REST API reference.

SR-IOV support is now available for Pensando DSC cards. OpenShift SR-IOV is supported, but you must set a static, Virtual Function (VF) media access control (MAC) address using the SR-IOV CNI config file when using SR-IOV.

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

Be aware that CIDR ranges for networks are not adjustable after cluster installation. Red Hat does not provide direct guidance on determining the range because it requires careful consideration of the number of pods created.

If you are using the OVN-Kubernetes cluster network provider, you can now enable IPsec encryption after cluster installation. For more information about how to enable IPsec, see Configuring IPsec encryption.

Additional MetalLB custom resource definitions (CRDs) have been added to support more complex configurations.

The following CRDs have been added:

With these enhancements, you can use the Operator for more complex configurations. For example, you can use the enhancements to isolate nodes or segment the network. In addition, the enhancements made to the FRRouting (FRR) logging component allow you to control the verbosity of the logs generated.

AddressPool

AddressPool

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

The

route.openshift.io/destination-ca-certificate-secret

See Creating a route using the destination CA certificate in the Ingress annotation for more information.

With hosted control planes for OpenShift Container Platform, you can host clusters at scale to reduce management costs, optimize cluster deployment time, and separate management and workload concerns. You can enable this deployment model as a Technology Preview feature when you install the multicluster engine for Kubernetes Operator version 2.0. For more information, see Overview of hosted control planes (Technology Preview).

Open Virtual Network (OVN) was redesigned to host its control plane and data store alongside the cluster’s control plane. With hosted control planes, OVN supports split control planes.

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

For clusters that run on RHOSP, Open vSwitch (OVS) hardware offloading is now generally available.

For more information, see Enabling OVS hardware offloading.

For clusters that run on RHOSP, the network functions virtualization deployment experience is improved. Changes for this release include:

These changes are reflected in simplified post-installation and network configuration documentation.

For OpenShift Container Platform installer-provisioned installations on Red Hat OpenStack Platform (RHOSP), VMware vSphere, or oVirt, keepalived is now configured with unicast as the default instead of multicast. You no longer need to allow multicast traffic. The unicast migration occurs a few minutes after the cluster finishes upgrading because all of the nodes must migrate at the same time. Having both multicast and unicast clusters at the same time should not result in any issues because keepalived treats unicast and multicast as completely separate.

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

For more information, see Azure File 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. Support for Cinder was provided in this feature in OpenShift Container Platform 4.8, and OpenShift Container Platform 4.11 now supports automatic migration for Cinder as generally available. CSI migration for Cinder is now enabled by default and requires no action by an administrator.

This feature automatically translates in-tree objects to their counterpart CSI representations and should be completely transparent to users. Translated objects are not stored on disk, and user data is not migrated.

While storage class referencing to the in-tree storage plugin will continue working, it is recommended that you switch the default storage class to the CSI storage class.

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. Support for Azure Disk was provided in this feature in OpenShift Container Platform 4.9, and OpenShift Container Platform 4.11 now supports automatic migration for Azure Disk as generally available. CSI migration for Azure Disk is now enabled by default and requires no action by an administrator.

This feature automatically translates in-tree objects to their counterpart CSI representations and should be completely transparent to users. Translated objects are not stored on disk, and user data is not migrated.

While storage class referencing to the in-tree storage plugin will continue working, it is recommended that you switch the default storage class to the CSI storage class.

For more information, see CSI automatic migration.

Starting with OpenShift Container Platform 4.3, expansion of Container Storage Interface (CSI) storage volumes after they have already been created became available as a Technology Preview feature, and is now generally available in OpenShift Container Platform 4.11.

For more information, see Expanding CSI volumes.

OpenShift Container Platform 4.11 supports Container Storage Interface (CSI) generic ephemeral volumes as generally available. Generic ephemeral volumes are a type of ephemeral volume that can be provided by all storage drivers that also support persistent volumes and dynamic provisioning.

For more information, see Generic ephemeral volumes.

OpenShift Container Platform 4.11 supports volume resize and snapshots for vSphere Container Storage Interface (CSI) Driver Operator with the following restrictions:

For more information, see CSI drivers supported by OpenShift Container Platform.

The default configuration of the Image Registry Operator now spreads image registry pods across topology zones to prevent delayed recovery times in case of a complete zone failure where all pods are impacted.

For more information, see Image Registry Operator distribution across availability zones.

Red Hat OpenShift Data Foundation registry storage supported in OpenShift Container Platform 4.11.

OpenShift Data Foundation integrates multiple storage types that you can use with the internal image registry including:

The default Red Hat-provided Operator catalogs for OpenShift Container Platform 4.11 releases in the file-based catalog format. OpenShift Container Platform 4.6 through 4.10 released in the SQLite database format. File-based catalogs are the latest iteration of the catalog format in Operator Lifecycle Manager (OLM). It is a plain text-based file in JSON or YAML and is a declarative configuration evolution of the earlier SQLite database format. Cluster administrators and users will not see any change to their install workflows and Operator consumption with the new catalog format.

For more information, see File-based catalogs.

Starting in OpenShift Container Platform 4.11 as a Technology Preview feature, the Operator SDK includes the tools and libraries to develop a Java-based Operator. Operator developers can take advantage of Java programming language support in the Operator SDK to build a Java-based Operator and manage its lifecycle.

For more information, see Getting started with Operator SDK for Java-based Operators.

As of OpenShift Container Platform 4.11, the

run bundle

For more information, see Working with bundle images.

As an Operator author, you can run the

bundle validate

For more information, see Validating Operator bundles. In earlier versions of OpenShift Container Platform, the Performance Addon Operator provided automatic, low latency performance tuning for applications. In OpenShift Container Platform 4.11, these functions are part of the Node Tuning Operator. The Node Tuning Operator is part of the standard installation for OpenShift Container Platform 4.11. If you upgrade to OpenShift Container Platform 4.11, the Node Tuning Operator removes the Performance Addon Operator and all related artifacts on startup.

For more information, see Node Tuning Operator.

You can now use machine sets to create compute machines that use a specific version of the Amazon EC2 Instance Metadata Service (IMDS). Machine sets can create compute machines that allow the use of both IMDSv1 and IMDSv2 or compute machines that require the use of IMDSv2.

For more information, see Machine set options for the Amazon EC2 Instance Metadata Service.

You can now create a machine set running on Azure that deploys machines with ultra disks. You can either deploy machines with ultra disks as data disks, or by using persistent volume claims (PVCs) that use in-tree or Container Storage Interface (CSI) PVCs.

For more information, see the following topics:

The

pd-balanced

The new platform support for Nutanix clusters includes the ability to manage machines using Machine API machine sets. For more information, see Creating a machine set on Nutanix.

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

The Machine Config Operator (MCO) now updates the affected nodes alphabetically by zone, based on the

topology.kubernetes.io/zone

For more information, see Machine config overview.

You will now receive alerts in the Alerting UI of the OpenShift Container Platform web console if the MCO attempts to renew an expired

kube-apiserver-to-kubelet-signer

For more information, see Pausing the machine config pools.

OpenShift Container Platform 4.11 introduces the Self Node Remediation Operator that replaces the Poison Pill Operator.

The Self Node Remediation Operator provides the following enhancements:

For more information, see Remediating nodes with the Self Node Remediation Operator.

You can now add worker nodes to single-node OpenShift clusters. This is useful for deployments in resource-constrained environments or at the network edge when you need to add additional capacity to your cluster.

For more information, see Worker nodes for single-node OpenShift clusters.

By default, the descheduler now runs in predictive mode, which means that it only simulates pod evictions. You can review the descheduler metrics to view details about pods that would be evicted.

To evict pods instead of simulating the evictions, change the descheduler mode to automatic.

For more information, see Evicting pods using the descheduler.

This release introduces the following customizations for the descheduler:

For more information, see Evicting pods using the descheduler.

The Node Maintenance Operator provides the following enhancements:

For more information, see Using the Node Maintenance Operator to place nodes in maintenance mode.

OpenShift Container Platform 4.11 introduces a new connector for the RHV API that adds automated log messages for all installations and oVirt components in a cluster.

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

A cluster administrator can now enable alert routing for user workload monitoring so that developers and other users can configure custom alerts and alert routing for their user-defined projects.

You now have the option to enable a separate instance of Alertmanager dedicated to sending alerts only for user-defined projects. This feature can help reduce the load on the default platform Alertmanager instance and can better separate user-defined alerts from default platform alerts.

You can now use the following authentication methods to access a remote write endpoint: AWS Signature Version 4, custom Authorization header, and OAuth 2.0. Before this release, you could only use TLS client and basic authentication.

The Query Browser on the Observe Metrics page of the OpenShift Container Platform web console adds various enhancements to improve your ability to create, browse, and manage PromQL queries. For example, administrators can now duplicate existing queries and use autocomplete suggestions when building and editing queries.

The scrape interval has been doubled for all Cluster Monitoring Operator (CMO) controlled ServiceMonitors on single-node OpenShift Container Platform deployments. The maximum interval is now two minutes.

This release introduces a Technology Preview feature in which administrators can create alerting rules based on existing platform monitoring metrics. This feature helps administrators to more quickly and easily create new alerting rules specific to their environments.

You can now add cluster ID labels to metrics being sent to remote write storage. You can then query these labels to identify the source cluster for a metric and distinguish that metric data from similar metric data sent by other clusters.

You can now use the Prometheus

/federate

You can now set the

enforcedBodySizeLimit

PrometheusScrapeBodySizeLimitHit

enforcedBodySizeLimit

You can now configure the maximum amount of disk space reserved for retained metrics storage for both default platform monitoring and user-workload monitoring. Before this release, you could not configure this setting.

You can now configure the retention time period for Thanos Ruler data in user-defined projects. Before this release, you could not change the default value of

24h

OpenShift Container Platform 4.11 supports a hinting mechanism for the Node Tuning Operator that can tune

PerformanceProfile

highPowerConsumption

realtime

The Raft algorithm allows for scaling of etcd members using a new

learner

learners

OpenShift Container Platform 4.11 introduces the

imageStorage

AgentServiceConfig

The

releaseImage

ClusterImageSet

The

openshiftVersion

AgentServiceConfig

OpenShift Container Platform 4.11 introduces the ability to configure the timeout values for the kubelet’s liveness, readiness, and startup probes for router deployments that are managed by the OpenShift Container Platform ingress operator. The ability to set larger timeout values can reduce the risk of unnecessary and unwanted restarts that are caused by short default timeout of 1 second.

For more information see, Configuring Ingress Controller (router) Liveness, Readiness, and Startup probes

You can decrease power consumption through the Node Tuning Operator by specifying CPUs in the

offlined

OpenShift Container Platform 4.11 introduces the Node Observability Operator in Technology Preview.

The Node Observability Operator provides the ability to:

For more information, see Requesting CRI-O and Kubelet profiling data using the Node Observability Operator.

In earlier versions of OpenShift Container Platform, the Performance Addon Operator provided automatic, low latency performance tuning for applications. In OpenShift Container Platform 4.11, these functions are part of the Node Tuning Operator. The Node Tuning Operator is part of the standard installation for OpenShift Container Platform 4.11. If you upgrade to OpenShift Container Platform 4.11, the Node Tuning Operator removes the Performance Addon Operator and all related artifacts on startup.

For more information, see Node Tuning Operator.

performance-addon-operator-must-gather

must-gather

In earlier version of OpenShift Container Platform, documentation for low latency tuning included references to the Performance Addon Operator. Since the Node Tuning Operator now provides low latency tuning, the documentation title changed from "Performance Addon Operator for low latency nodes" to "Low latency tuning", and multiple cross-references to this document were updated accordingly. For more information, see Low latency tuning.

For hub and spoke deployments in which spoke clusters require out-of-tree driver support, you can use the Special Resource Operator (SRO) deployed in the hub cluster to manage the deployment of the required kernel module(s) to one or more managed clusters. This uses Red Hat Advanced Cluster Management (RHACM) and no longer requires the use of Node Feature Discovery (NFD). For more information, see Building and running the simple-kmod SpecialResource for a hub-and-spoke topology.

When upgrading a cluster in which special resources are being managed, you can run the pre-upgrade custom resource to verify that a new driver container exists to support a kernel update. This helps avoid possible disruption of managed special resources. The documentation for this feature is currently unavailable and is targeted for release at a later date.

The Special Resource Operator (SRO) includes a consistent log output format with greater message detail for troubleshooting.

Before this update, SRO did not support connecting to registries in disconnected environments. This release provides support for disconnected environments for which the driver container is hosted in a registry outside of the OpenShift Container Platform cluster.

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

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

The following OpenID Connect (OIDC) providers are now tested and supported with OpenShift Container Platform:

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

Pod security admission is now enabled on OpenShift Container Platform.

Pod admission is enforced by both pod security and security context constraints (SCC) admissions. Pod security admission runs globally with

privileged

restricted

A controller monitors the SCC-related permissions of service accounts in user-created namespaces and automatically labels these namespaces with pod security admission

warn

audit

To improve workload security in accordance with the

restricted

They correspond to older, similarly named SCCs, but with the following enhancements:

In OpenShift Container Platform 4.11, the

restricted-v2

restricted

restricted-v2

restricted

restricted

restricted

You can enable synchronization for most namespaces and disable synchronization for all namespaces.

For this release, namespaces that are prefixed with

openshift-

For more information, see Understanding and managing pod security admission.

The following

oc

Use the

oc create token

Red Hat Virtualization (RHV) will be deprecated in an upcoming release of OpenShift Container Platform. Support for OpenShift Container Platform on RHV will be removed from a future OpenShift Container Platform release, currently planned as OpenShift Container Platform 4.14.

In OpenShift Container Platform 4.11, support for VMware vSphere 7.0 Update 1 or earlier is deprecated. While vSphere 7.0 Update 1 or earlier remains fully supported, Red Hat recommends that you use vSphere 7.0 Update 2 or later, up to but not including version 8. vSphere 8 is not supported.

In OpenShift Container Platform 4.11, support for VMware ESXi 7.0 Update 1 or earlier is deprecated. While EXSi 7.0 Update 1 or earlier remains fully supported, Red Hat recommends that you use ESXi 7.0 Update 2 or later.

In OpenShift Container Platform 4.11, the

pidsLimit

logSizeMax

ContainerRuntimeConfig

podPidsLimit

containerLogMaxSize

KubeletConfig

podPidsLimit

4096

Support for using Red Hat Enterprise Linux (RHEL) 7 with the OpenShift CLI (

oc

oc

The following OpenShift CLI (

oc

The Grafana component is no longer a part of the OpenShift Container Platform 4.11 monitoring stack. As an alternative, go to Observe Dashboards in the OpenShift Container Platform web console to view monitoring dashboards.

Access to the third-party Prometheus and Grafana user interfaces have been removed from the OpenShift Container Platform 4.11 monitoring stack. As an alternative, click Observe in the OpenShift Container Platform web console to view alerting, metrics, dashboards, and metrics targets for monitoring components.

In OpenShift Container Platform 4.11, support for virtual hardware version 13 is removed. Support for virtual hardware version 13 was deprecated in OpenShift Container Platform 4.9. Red Hat recommends that you use virtual hardware version 15 or later.

In OpenShift Container Platform 4.11, support for VMware vSphere 6.7 Update 2 or earlier is removed. Support for vSphere 6.7 Update 2 or earlier was deprecated in OpenShift Container Platform 4.9. Red Hat recommends that you use vSphere 7.0 Update 2 or later, up to but not including version 8. vSphere 8 is not supported.

In OpenShift Container Platform 4.11, support for VMware ESXi 6.7 Update 2 or earlier is removed. Support for ESXi 6.7 Update 2 or earlier was deprecated in OpenShift Container Platform 4.10. Red Hat recommends that you use ESXi 7.0 Update 2 or later.

In OpenShift Container Platform 4.11, support for

snapshot.storage.k8s.io/v1beta1

snapshot.storage.k8s.io/v1beta1

snapshot.storage.k8s.io/v1

v1beta1

Support for deploying custom schedulers manually has been removed with this release. Use the Secondary Scheduler Operator for Red Hat OpenShift instead to deploy a custom secondary scheduler in OpenShift Container Platform.

Support for deploying single-node OpenShift clusters with OpenShiftSDN has been removed with this release. OVN-Kubernetes is the default networking solution for single-node OpenShift deployments.

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

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

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

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

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