Hosted control planes release notes

Before this update, deploying a hosted control plane on OpenShift Virtualization with IPv4 or IPv6 dual-stack networking failed because the Cluster Network Operator did not recognize KubeVirt as a supported platform for dual-stack. As a consequence, hosted clusters could not be deployed on OpenShift Virtualization with dual-stack networking. With this release, support is added for deploying a hosted control plane on OpenShift Virtualization with KubeVirt. The Cluster Network Operator (CNO) now recognizes KubeVirt as a supported platform for dual-stack, which enables the successful deployment of hosted control planes with IPv4/IPv6 dual-stack networking. This enhancement ensures a smoother deployment process for dual-stack networking configurations. (OCPBUGS-69941)

Before this update, the GenerateNodePools() function of the CLI incorrectly set AzureMarketplace to nil when you specified the --image-generation flag without additional marketplace flags, which discarded your preference. Also, the nodepool controller failed to set ImageGeneration when creating images from the release payload, which caused them to default to Gen2. As a consequence, when users attempted to create Azure hosted clusters by using --image-generation Gen1, the NodePools were incorrectly provisioned with Gen2 images, which ignored the explicit configuration. With this release, the CLI is modified to preserve your preference by creating a proper AzureMarketplaceImage structure, and the nodepool controller explicitly sets the generation field based on the release payload (mapping Gen1 for HyperVGen1 and Gen2 for HyperVGen2). As a result, the` --image-generation` flag is now fully respected, which allows you to successfully deploy NodePool objects with their chosen image generation without being overwritten by system defaults. (OCPBUGS-63613)

Before this update, when a hosted cluster used an external DNS and the PublicAndPrivate endpoint access type, the allowedCIDRBlocks parameter was applied to the kube-apiserver service instead of the external router LoadBalancer service. Because external traffic to the kube-apiserver service flows through the router when the external DNS is configured, the CIDR restrictions were not enforced and external access was unrestricted. With this update, the LoadBalancerSourceRanges configuration is applied to the external router LoadBalancer service. As a result, external kube-apiserver access is properly restricted to the specified allowedCIDRBlocks values. (OCPBUGS-61941)

Before this update, deploying hosted control planes 4.20 with user-supplied ignition-server-serving-cert and ignition-server-ca-cert secrets, along with the disable-pki-reconciliation annotation, caused the system to remove the user-supplied ignition secrets and the ignition-server pods to fail. With this release, the ignition-server secrets are preserved during reconciliation after removing the delete action for the disable-pki-reconciliation annotation, ensuring that the ignition-server pods start up completely. (OCPBUGS-61776)

Before this update, the hosted control plane (hcp) CLI and control plane operator instantiated Azure SDK clients without passing cloud configuration options, which caused all clients to default to Azure Public Cloud. As a consequence, creating or managing hosted clusters in Azure Government Cloud or Azure China Cloud failed because the SDK clients could not connect to the correct cloud endpoints. With this update, all Azure SDK client instantiations use the cloud configuration specified in the hosted cluster platform settings. As a result, the hcp CLI and control plane operator correctly support Azure Government Cloud and Azure China Cloud in addition to Azure Public Cloud. (OCPBUGS-33372)

Before this update, the following test failed more than expected:`TestExternalOIDCTechPreview/Main/[OCPFeatureGate:ExternalOIDCWithUIDAndExtraClaimMappings]_Test_external_OIDC_userInfo_Extra`. As a consequence, the user experience was disrupted by a test failure in the external OIDC feature. With this release, the bug fix ensures that the ExternalOIDCWithUIDAndExtraClaimMappings test passes in version 4.20. As a result, the test failures in the external OIDC feature are fixed, improving user authentication in 4.20 and later versions. (OCPBUGS-63622)

Not Available

Technology Preview

General Availability

Deprecated

Removed

If the annotation and the ManagedCluster resource name do not match, the multicluster engine for Kubernetes Operator console displays the cluster as Pending import. The cluster cannot be used by the multicluster engine Operator. The same issue happens when there is no annotation and the ManagedCluster name does not match the Infra-ID value of the HostedCluster resource.

When you use the multicluster engine for Kubernetes Operator console to add a new node pool to an existing hosted cluster, the same version of OKD might appear more than once in the list of options. You can select any instance in the list for the version that you want.

When a node pool is scaled down to 0 workers, the list of hosts in the console still shows nodes in a Ready state. You can verify the number of nodes in two ways:

When you create a hosted cluster in an environment that uses the dual-stack network, you might encounter pods stuck in the ContainerCreating state. This issue occurs because the openshift-service-ca-operator resource cannot generate the metrics-tls secret that the DNS pods need for DNS resolution. As a result, the pods cannot resolve the Kubernetes API server. To resolve this issue, configure the DNS server settings for a dual stack network.

If you created a hosted cluster in the same namespace as its managed cluster, detaching the managed hosted cluster deletes everything in the managed cluster namespace including the hosted cluster. The following situations can create a hosted cluster in the same namespace as its managed cluster:

When you use the console or API to specify an IPv6 address for the spec.services.servicePublishingStrategy.nodePort.address field of a hosted cluster, a full IPv6 address with 8 hextets is required. For example, instead of specifying 2620:52:0:1306::30, you need to specify 2620:52:0:1306:0:0:0:30.

In hosted control planes on OKD Virtualization, if you store all hosted cluster information in a shared namespace and then back up and restore a hosted cluster, you might unintentionally change other hosted clusters. To avoid this issue, back up and restore only hosted clusters that use labels, or avoid storing all hosted cluster information in a shared namespace.

For version 4.21, hosted control planes pins all Cluster API images to the 4.20.10-multi release image for compatibility reasons. Hosted control planes pins the images when Cluster API deployments are generated. The 4.20.10-multi image must always be mirrored and available in order for the Cluster API to work with hosted control planes version 4.21.