Hosted control planes release notes

Previously, you could not create node pools that use ARM64 architecture on a hosted control planes cluster with the platform parameter set to either agentBareMetal or none. This issue did not exist for a hosted control planes cluster that runs on an AWS or an Microsoft Azure platform. With this release, a fix ensures that you can now create node pools that use ARM64 architecture in a hosted control planes cluster that has platform set to either agentBareMetal or none. (OCPBUGS-48579)

Previously, when you attempted to use the hosted control planes CLI to create a cluster in a disconnected environment, the installation command failed. An issue existed with the registry that hosts the command. With this release, a fix to the command registry means that you can use the hosted control planes CLI to create a cluster in a disconnected environment. (OCPBUGS-48170)

Previously, incorrect addresses were being passed to the Kubernetes EndpointSlice on a cluster, and this issue prevented the installation of the MetalLB Operator on an Agent-based cluster in an IPv6 disconnected environment. With this release, a fix modifies the address evaluation method. Red Hat Marketplace pods can now successfully connect to the cluster API server, so that the installation of MetalLB Operator and handling of ingress traffic in IPv6 disconnected environments can occur. (OCPBUGS-46665)

Previously, in hosted control planes on the Agent platform, ARM64 architecture was not allowed in the NodePool API. As a consequence, heterogeneous clusters could not be deployed on the Agent platform. In this release, the API now allows ARM64 architecture node pools on the Agent platform. (OCPBUGS-4673)

Previously, the default node-monitor-grace-period value was 50 seconds. As a consequence, nodes did not stay ready for the duration of time that Kubernetes components needed to reconnect, coordinate, and complete their requests. With this release, the default node-monitor-grace-period value is 55 seconds. As a result, the issue is resolved and deployments have enough time to be completed. (OCPBUGS-46008)

Previously, the provider ID for the IBMPowerVSMachine object was not populated properly, due to the improper retrieval of IBM Cloud Workspace ID. As a consequence, any certificate signing requests (CSRs) were pending in hosted clusters. With this release, the provider ID is properly populated for the IBMPowerVSMachine object. As a result, no CSRs are pending, and all COs are moved to the available state. (OCPBUGS-44944)

Previously, when you created a hosted cluster by using a shared VPC where the private DNS hosted zones existed in the cluster creator account, the private link controller failed to create the route53 DNS records in the local zone. With this release, the ingress shared role adds records to the private link controller. The VPC endpoint is used to share the role to create the VPC endpoint in the VPC owner account. A hosted cluster is created in a shared VPC configuration, where the private hosted zones exist in the cluster creator account. (OCPBUGS-44630)

Previously, when the hosted cluster controllerAvailabilityPolicy parameter was set to SingleReplica, the podAntiAffinity rules on networking components blocked the availability of the components. With this release, the issue is resolved. (OCPBUGS-39313)

Previously, periodic conformance jobs in hosted control planes failed because of changes to the core operating system. These failed jobs caused the OpenShift API deployment to fail. With this release, an update recursively copies individual trusted certificate authority (CA) certificates instead of copying a single file, so that the periodic conformance jobs succeed and the OpenShift API runs as expected. (OCPBUGS-38943)

Previously, you could not create NodePool resources with ARM64 architecture on non-AWS or Azure platforms. This bug resulted in validation errors that prevented the addition of bare-metal compute nodes and caused CEL validation blocks when creating a NodePool resource. The fix modifies the NodePool spec validation rules by adding "self.platform.type == 'None'". As a result, you can now create NodePool resources with ARM64 architecture specifications on non-AWS or Azure bare-metal platforms, expanding functionality. (OCPBUGS-46440)

Previously, when you created a hosted cluster in a shared VPC, the private link controller sometimes failed to assume the shared VPC role to manage the VPC endpoints in the shared VPC. With this release, a client is created for every reconciliation in the private link controller so that you can recover from invalid clients. As a result, the hosted cluster endpoints and the hosted cluster are created successfully. (OCPBUGS-45184)

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 the following DNS-related issues:

On the Agent platform, the hosted control planes feature periodically rotates the token that the Agent uses to pull ignition. As a result, if you have an Agent resource that was created some time ago, it might fail to pull ignition. As a workaround, in the Agent specification, delete the secret of the IgnitionEndpointTokenReference property then add or modify any label on the Agent resource. The system re-creates the secret with the new token.

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.