--- title: Deploying hosted control planes on non-bare-metal agent machines --- # Deploying hosted control planes on non-bare-metal agent machines {#hcp-deploy-non-bm} To maintain infrastructure flexibility while using existing virtualization layers, you can deploy hosted control planes on non-bare-metal Agent machines. You can use the management benefits of the Agent platform when running on virtualized environments or other cloud-based virtual machines. > [!IMPORTANT] > Hosted control planes on non-bare-metal agent machines is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. > > For more information about the support scope of Red Hat Technology Preview features, see [Technology Preview Features Support Scope](https://access.redhat.com/support/offerings/techpreview/). You can deploy hosted control planes by configuring a cluster to function as a hosting cluster. The hosting cluster is an OpenShift Container Platform cluster where the control planes are hosted. The hosting cluster is also known as the management cluster. > [!NOTE] > The management cluster is not the same thing as the *managed* cluster. A managed cluster is a cluster that the hub cluster manages. The hosted control planes feature is enabled by default. The multicluster engine Operator supports only the default `local-cluster` managed hub cluster. On Red Hat Advanced Cluster Management (RHACM) 2.10, you can use the `local-cluster` managed hub cluster as the hosting cluster. A *hosted cluster* is an OpenShift Container Platform cluster with its API endpoint and control plane that are hosted on the hosting cluster. The hosted cluster includes the control plane and its corresponding data plane. You can use the multicluster engine Operator console or the `hcp` command-line interface (CLI) to create a hosted cluster. The hosted cluster is automatically imported as a managed cluster. If you want to disable this automatic import feature, see "Disabling the automatic import of hosted clusters into multicluster engine Operator". **Additional resources** {._additional-resources} - [Disabling the automatic import of hosted clusters into multicluster engine Operator](/openshift-docs-markdown/hosted_control_planes/hcp-import#hcp-import-disable_hcp-import) ## Preparing to deploy hosted control planes on non-bare-metal agent machines {#hcp-non-bm-prepare_hcp-deploy-non-bm} Before you deploy hosted control planes on non-bare-metal agent machines, ensure that you understand requirements for the deployment. - You can add agent machines as a worker node to a hosted cluster by using the Agent platform. Agent machine represents a host booted with a Discovery Image and ready to be provisioned as an OpenShift Container Platform node. The Agent platform is part of the central infrastructure management service. For more information, see "Enabling the central infrastructure management service". - All hosts that are not bare metal require a manual boot with a Discovery Image ISO that the central infrastructure management provides. - When you scale up the node pool, a machine is created for every replica. For every machine, the Cluster API provider finds and installs an Agent that is approved, is passing validations, is not currently in use, and meets the requirements that are specified in the node pool specification. You can monitor the installation of an Agent by checking its status and conditions. - When you scale down a node pool, Agents are unbound from the corresponding cluster. Before you can reuse the Agents, you must restart them by using the Discovery image. - When you configure storage for hosted control planes, consider the recommended etcd practices. To ensure that you meet the latency requirements, dedicate a fast storage device to all hosted control planes etcd instances that run on each control-plane node. You can use LVM storage to configure a local storage class for hosted etcd pods. For more information, see "Recommended etcd practices" and "Persistent storage using logical volume manager storage" in the OpenShift Container Platform documentation. **Additional resources** {._additional-resources} - [Enabling the central infrastructure management service (Red Hat Advanced Cluster Management documentation)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.16/html/clusters/cluster_mce_overview#enable-cim) - [Recommended etcd practices](/openshift-docs-markdown/etcd/etcd-practices#recommended-etcd-practices) - [Persistent storage using logical volume manager storage](/openshift-docs-markdown/storage/persistent_storage_local/persistent-storage-using-lvms#persistent-storage-using-lvms_logical-volume-manager-storage) ### Prerequisites for deploying hosted control planes on non-bare-metal agent machines {#hcp-non-bm-prereqs_hcp-deploy-non-bm} Before you deploy hosted control planes on non-bare-metal agent machines, ensure you meet the prerequisites. - You must have multicluster engine for Kubernetes Operator 2.5 or later installed on an OpenShift Container Platform cluster. You can install the multicluster engine Operator as an Operator from the OpenShift Container Platform software catalog. - You must have at least one managed OpenShift Container Platform cluster for the multicluster engine Operator. The `local-cluster` management cluster is automatically imported. For more information about the `local-cluster`, see "Advanced configuration" in the Red Hat Advanced Cluster Management documentation. You can check the status of your management cluster by running the following command: ```terminal $ oc get managedclusters local-cluster ``` - You have enabled central infrastructure management. For more information, see "Enabling the central infrastructure management service" in the Red Hat Advanced Cluster Management documentation. - You have installed the `hcp` command-line interface. - Your hosted cluster has a cluster-wide unique name. - You are running the management cluster and workers on the same infrastructure. **Additional resources** {._additional-resources} - [Advanced configuration (Red Hat Advanced Cluster Management documentation)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/latest/html/clusters/cluster_mce_overview#advanced-config-engine) - [Enabling the central infrastructure management service (Red Hat Advanced Cluster Management documentation)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/latest/html/clusters/cluster_mce_overview#enable-cim) ### Firewall, port, and service requirements for non-bare-metal agent machines {#hcp-non-bm-firewall-port-svc-reqs_hcp-deploy-non-bm} You must meet the firewall and port requirements so that ports can communicate between the management cluster, the control plane, and hosted clusters. > [!NOTE] > Services run on their default ports. However, if you use the `NodePort` publishing strategy, services run on the port that is assigned by the `NodePort` service. Use firewall rules, security groups, or other access controls to restrict access to only required sources. Avoid exposing ports publicly unless necessary. For production deployments, use a load balancer to simplify access through a single IP address. A hosted control plane exposes the following services on non-bare-metal agent machines: - `APIServer` - The `APIServer` service runs on port 6443 by default and requires ingress access for communication between the control plane components. - If you use MetalLB load balancing, allow ingress access to the IP range that is used for load balancer IP addresses. - `OAuthServer` - The `OAuthServer` service runs on port 443 by default when you use the route and ingress to expose the service. - If you use the `NodePort` publishing strategy, use a firewall rule for the `OAuthServer` service. - `Konnectivity` - The `Konnectivity` service runs on port 443 by default when you use the route and ingress to expose the service. - The `Konnectivity` agent establishes a reverse tunnel to allow the control plane to access the network for the hosted cluster. The agent uses egress to connect to the `Konnectivity` server. The server is exposed by using either a route on port 443 or a manually assigned `NodePort`. - If the cluster API server address is an internal IP address, allow access from the workload subnets to the IP address on port 6443. - If the address is an external IP address, allow egress on port 6443 to that external IP address from the nodes. - `Ignition` - The `Ignition` service runs on port 443 by default when you use the route and ingress to expose the service. - If you use the `NodePort` publishing strategy, use a firewall rule for the `Ignition` service. You do not need the following services on non-bare-metal agent machines: - `OVNSbDb` - `OIDC` ### Infrastructure requirements for non-bare-metal agent machines {#hcp-non-bm-infra-reqs_hcp-deploy-non-bm} The Agent platform does not create any infrastructure, but it has several requirements. - Agents: An *Agent* represents a host that is booted with a discovery image and is ready to be provisioned as an OpenShift Container Platform node. - DNS: The API and ingress endpoints must be routable. **Additional resources** {._additional-resources} - [Recommended etcd practices](/openshift-docs-markdown/etcd/etcd-practices#recommended-etcd-practices) - [Persistent storage using logical volume manager storage](/openshift-docs-markdown/storage/persistent_storage_local/persistent-storage-using-lvms#persistent-storage-using-lvms_logical-volume-manager-storage) - [Disabling the automatic import of hosted clusters into multicluster engine Operator](/openshift-docs-markdown/hosted_control_planes/hcp-import#hcp-import-disable_hcp-import) - [Manually enabling the hosted control planes feature](/openshift-docs-markdown/hosted_control_planes/hcp-prepare/hcp-enable-disable#hcp-enable-manual_hcp-enable-disable) - [Disabling the hosted control planes feature](/openshift-docs-markdown/hosted_control_planes/hcp-prepare/hcp-enable-disable#hcp-disable-feature_hcp-enable-disable) ## DNS configuration on non-bare-metal agent machines {#hcp-non-bm-dns_hcp-deploy-non-bm} The API Server for the hosted cluster is exposed as a `NodePort` service. A DNS entry must exist for `api..` that points to destination where the API Server can be reached. The DNS entry can be as simple as a record that points to one of the nodes in the managed cluster that is running the hosted control plane. The entry can also point to a load balancer that is deployed to redirect incoming traffic to the ingress pods. The following examples show how to configure DNS for specific environments. ```text {title="Example DNS configuration for a connected environment on an IPv4 network"} api.example.krnl.es. IN A 192.168.122.20 api.example.krnl.es. IN A 192.168.122.21 api.example.krnl.es. IN A 192.168.122.22 api-int.example.krnl.es. IN A 192.168.122.20 api-int.example.krnl.es. IN A 192.168.122.21 api-int.example.krnl.es. IN A 192.168.122.22 `*`.apps.example.krnl.es. IN A 192.168.122.23 ``` ```text {title="Example DNS configuration for a disconnected environment on an IPv6 network"} api.example.krnl.es. IN A 2620:52:0:1306::5 api.example.krnl.es. IN A 2620:52:0:1306::6 api.example.krnl.es. IN A 2620:52:0:1306::7 api-int.example.krnl.es. IN A 2620:52:0:1306::5 api-int.example.krnl.es. IN A 2620:52:0:1306::6 api-int.example.krnl.es. IN A 2620:52:0:1306::7 `*`.apps.example.krnl.es. IN A 2620:52:0:1306::10 ``` ```text {title="Example DNS configuration for a disconnected environment on a dual stack network"} host-record=api-int.hub-dual.dns.base.domain.name,192.168.126.10 host-record=api.hub-dual.dns.base.domain.name,192.168.126.10 address=/apps.hub-dual.dns.base.domain.name/192.168.126.11 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,192.168.126.20 dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,192.168.126.21 dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,192.168.126.22 dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,192.168.126.25 dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,192.168.126.26 host-record=api-int.hub-dual.dns.base.domain.name,2620:52:0:1306::2 host-record=api.hub-dual.dns.base.domain.name,2620:52:0:1306::2 address=/apps.hub-dual.dns.base.domain.name/2620:52:0:1306::3 dhcp-host=aa:aa:aa:aa:10:01,ocp-master-0,[2620:52:0:1306::5] dhcp-host=aa:aa:aa:aa:10:02,ocp-master-1,[2620:52:0:1306::6] dhcp-host=aa:aa:aa:aa:10:03,ocp-master-2,[2620:52:0:1306::7] dhcp-host=aa:aa:aa:aa:10:06,ocp-installer,[2620:52:0:1306::8] dhcp-host=aa:aa:aa:aa:10:07,ocp-bootstrap,[2620:52:0:1306::9] ``` For this configuration, be sure to include DNS entries for both IPv4 and IPv6. ## Defining a custom DNS name {#hcp-custom-dns_hcp-deploy-non-bm} As a cluster administrator, you can create a hosted cluster with an external API DNS name that differs from the internal endpoint that gets used for node bootstraps and control plane communication. You might want to define a different DNS name for the following reasons: - To replace the user-facing TLS certificate with one from a public CA without breaking the control plane functions that bind to the internal root CA - To support split-horizon DNS and NAT scenarios - To ensure a similar experience to standalone control planes, where you can use functions, such as the `Show Login Command` function, with the correct `kubeconfig` and DNS configuration You can define a DNS name either during your initial setup or during postinstallation operations, by entering a domain name in the `kubeAPIServerDNSName` parameter of a `HostedCluster` object. **Prerequisites** - You have a valid TLS certificate that covers the DNS name that you set in the `kubeAPIServerDNSName` parameter. - You have a resolvable DNS name URI that can reach and point to the correct address. **Procedure** - In the specification for the `HostedCluster` object, add the `kubeAPIServerDNSName` parameter and the address for the domain and specify which certificate to use, as shown in the following example: ```yaml #... spec: configuration: apiServer: servingCerts: namedCertificates: - names: - xxx.example.com - yyy.example.com servingCertificate: name: kubeAPIServerDNSName: ``` The value for the `kubeAPIServerDNSName` parameter must be a valid and addressable domain. After you define the `kubeAPIServerDNSName` parameter and specify the certificate, the Control Plane Operator controllers create a `kubeconfig` file named `custom-admin-kubeconfig`, where the file gets stored in the `HostedControlPlane` namespace. The generation of certificates happen from the root CA, and the `HostedControlPlane` namespace manages their expiration and renewal. The Control Plane Operator reports a new `kubeconfig` file named `CustomKubeconfig` in the `HostedControlPlane` namespace. That file uses the defined new server in the `kubeAPIServerDNSName` parameter. A reference for the custom `kubeconfig` file exists in the `status` parameter as `CustomKubeconfig` of the `HostedCluster` object. The `CustomKubeConfig` parameter is optional, and you can add the parameter only if the `kubeAPIServerDNSName` parameter is not empty. After you set the `CustomKubeConfig` parameter, the parameter triggers the generation of a secret named `-custom-admin-kubeconfig` in the `HostedCluster` namespace. You can use the secret to access the `HostedCluster` API server. If you remove the `CustomKubeConfig` parameter during postinstallation operations, deletion of all related secrets and status references occur. > [!NOTE] > Defining a custom DNS name does not directly impact the data plane, so no expected rollouts occur. The `HostedControlPlane` namespace receives the changes from the HyperShift Operator and deletes the corresponding parameters. If you remove the `kubeAPIServerDNSName` parameter from the specification for the `HostedCluster` object, all newly generated secrets and the `CustomKubeconfig` reference are removed from the cluster and from the `status` parameter. ## Creating a hosted cluster on non-bare-metal agent machines by using the CLI {#hcp-non-bm-hc_hcp-deploy-non-bm} When you create a hosted cluster with the Agent platform, the HyperShift Operator installs the Agent Cluster API provider in the hosted control plane namespace. You can create a hosted cluster on bare metal or import one. > [!NOTE] > - Each hosted cluster must have a cluster-wide unique name. A hosted cluster name cannot be the same as any existing managed cluster in order for multicluster engine Operator to manage it. > - Do not use `clusters` as a hosted cluster name. > - A hosted cluster cannot be created in the namespace of a multicluster engine Operator managed cluster. **Procedure** 1. Create the hosted control plane namespace by entering the following command: ```terminal $ oc create ns - ``` Replace `` with your hosted cluster namespace name, for example, `my-hosted-cluster-namespace`. Replace `` with your hosted cluster name. 2. Create a hosted cluster by entering the following command: ```terminal $ hcp create cluster agent \ --name=my-hosted-cluster \ --pull-secret=/user/name/pullsecret \ --agent-namespace=clusters-example \ --base-domain=krnl.es \ --api-server-address=api.my-hosted-cluster.krnl.es \ --etcd-storage-class=lvm-storageclass \ --ssh-key ~/.ssh/id_rsa.pub \ --namespace my-hosted-cluster-namespace \ --control-plane-availability-policy HighlyAvailable \ --release-image=quay.io/openshift-release-dev/ocp-release:4.22.0-multi \ --disable-cluster-capabilities= \ --enable-cluster-capabilities= \ --node-pool-replicas 3 ``` - `--name` specifies the name of your hosted cluster. - `--pull-secret` specifies the path to your pull secret. - `--agent-namespace` specifies your hosted control plane namespace. Ensure that agents are available in this namespace by using the `oc get agent -n ` command. - `--base-domain` specifies your base domain. - `--api-server-address` The `--api-server-address` flag defines the IP address that is used for the Kubernetes API communication in the hosted cluster. If you do not set the `--api-server-address` flag, you must log in to connect to the management cluster. - `--etcd-storage-class` specifies the etcd storage class name. Verify that you have a default storage class configured for your cluster. Otherwise, you might end up with pending PVCs. - `--ssh_key` specifies the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`. - `--namespace` specifies your hosted cluster namespace. - `--control-plane-availability-policy` specifies the availability policy for the hosted control plane components. Supported options are `SingleReplica` and `HighlyAvailable`. The default value is `HighlyAvailable`. - `--release-image` specifies the supported OpenShift Container Platform version that you want to use. - `--disable-cluster-capabilities` specifies that you want to disable optional capabilities in the hosted cluster. This flag is optional. For more information, see "Capabilities for hosted clusters". - `--enable-cluster-capabilities` specifies that you want to enable optional capabilities in the hosted cluster. This flag is optional. For more information, see "Capabilities for hosted clusters". - `--node-pool-replicas` specifies the node pool replica count. You must specify the replica count as `0` or greater to create the same number of replicas. Otherwise, no node pools are created. **Verification** - After a few moments, verify that your hosted control plane pods are up and running by entering the following command: ```terminal $ oc -n - get pods ``` ```terminal {title="Example output"} NAME READY STATUS RESTARTS AGE catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s ``` **Additional resources** {._additional-resources} - [Manually importing a hosted cluster](/openshift-docs-markdown/hosted_control_planes/hcp-import#hcp-import-manual_hcp-import) - [Configuring a custom API server certificate in a hosted cluster](/openshift-docs-markdown/hosted_control_planes/hcp-certificates#hcp-custom-cert_hcp-certificates) - [Extracting the release image digest](/openshift-docs-markdown/hosted_control_planes/hcp-disconnected/hcp-deploy-dc-bm#hcp-dc-extract_hcp-deploy-dc-bm) ## Creating a hosted cluster on non-bare-metal agent machines by using the web console {#hcp-non-bm-hc-console_hcp-deploy-non-bm} You can create a hosted cluster on non-bare-metal agent machines by using the OpenShift Container Platform web console. **Prerequisites** - You have access to the cluster with `cluster-admin` privileges. - You have access to the OpenShift Container Platform web console. **Procedure** 1. Open the OpenShift Container Platform web console and log in by entering your administrator credentials. 2. In the console header, select **All Clusters**. 3. Click **Infrastructure → Clusters**. 4. Click **Create cluster Host inventory → Hosted control plane**. The **Create cluster** page is displayed. 5. On the **Create cluster** page, follow the prompts to enter details about the cluster, node pools, networking, and automation. As you enter details about the cluster, you might find the following tips useful: - If you want to use predefined values to automatically populate fields in the console, you can create a host inventory credential. For more information, see *Creating a credential for an on-premises environment*. - On the **Cluster details** page, the pull secret is your OpenShift Container Platform pull secret that you use to access OpenShift Container Platform resources. If you selected a host inventory credential, the pull secret is automatically populated. - On the **Node pools** page, the namespace contains the hosts for the node pool. If you created a host inventory by using the console, the console creates a dedicated namespace. - On the **Networking** page, you select an API server publishing strategy. The API server for the hosted cluster can be exposed either by using an existing load balancer or as a service of the `NodePort` type. A DNS entry must exist for the `api..` setting that points to the destination where the API server can be reached. This entry can be a record that points to one of the nodes in the management cluster or a record that points to a load balancer that redirects incoming traffic to the Ingress pods. 6. Review your entries and click **Create**. The **Hosted cluster** view is displayed. 7. Monitor the deployment of the hosted cluster in the **Hosted cluster** view. If you do not see information about the hosted cluster, ensure that **All Clusters** is selected, and click the cluster name. Wait until the control plane components are ready. This process can take a few minutes. 8. To view the node pool status, scroll to the **NodePool** section. The process to install the nodes takes about 10 minutes. You can also click **Nodes** to confirm whether the nodes joined the hosted cluster. **Additional resources** {._additional-resources} - [Creating a credential for an on-premises environment (Red Hat Advanced Cluster Management documentation)](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.15/html/clusters/cluster_mce_overview#creating-a-credential-for-an-on-premises-environment) - [Accessing the web console](/openshift-docs-markdown/web_console/web-console#web-console-overview) - [Configuring a custom API server certificate in a hosted cluster](/openshift-docs-markdown/hosted_control_planes/hcp-certificates#hcp-custom-cert_hcp-certificates) ## Creating a hosted cluster on non-bare-metal agent machines by using a mirror registry {#hcp-non-bm-hc-mirror_hcp-deploy-non-bm} You can use a mirror registry to create a hosted cluster on non-bare-metal agent machines by specifying the `--image-content-sources` flag in the `hcp create cluster` command. **Procedure** 1. Create a YAML file to define Image Content Source Policies (ICSP). See the following example: ```yaml - mirrors: - brew.registry.redhat.io source: registry.redhat.io - mirrors: - brew.registry.redhat.io source: registry.stage.redhat.io - mirrors: - brew.registry.redhat.io source: registry-proxy.engineering.redhat.com ``` 2. Save the file as `icsp.yaml`. This file contains your mirror registries. 3. To create a hosted cluster by using your mirror registries, run the following command: ```terminal $ hcp create cluster agent \ --name=my-hosted-cluster \ --pull-secret=/user/name/pullsecret\ --agent-namespace=clusters-example \ --base-domain=krnl.es \ --api-server-address=api.my-hosted-cluster.krnl.es \ --image-content-sources icsp.yaml \ --ssh-key ~/.ssh/id_rsa.pub \ --namespace my-hosted-cluster-namespace \ --release-image=quay.io/openshift-release-dev/ocp-release:4.22.0-multi ``` - `--name` specifies the name of your hosted cluster. - `--pull-secret` specifies the path to your pull secret. - `--agent-namespace` specifies your hosted control plane namespace. Ensure that agents are available in this namespace by using the `oc get agent -n ` command. - `--base-domain` specifies your base domain. - `--api-server-address` defines the IP address that is used for the Kubernetes API communication in the hosted cluster. If you do not set the `--api-server-address` flag, you must log in to connect to the management cluster. - `--image-content-sources` specifies the `icsp.yaml` file that defines ICSP and your mirror registries. - `--ssh-key` specifies the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`. - `--namespace` specifies your hosted cluster namespace. - `--release-image` specifies the supported OpenShift Container Platform version that you want to use. If you are using a disconnected environment, replace the version with the digest image. To extract the OpenShift Container Platform release image digest, see "Extracting the release image digest". **Additional resources** {._additional-resources} - [Accessing the hosted cluster](/openshift-docs-markdown/hosted_control_planes/hcp-manage/hcp-manage-bm#hcp-bm-access_hcp-manage-bm) - [Configuring a custom API server certificate in a hosted cluster](/openshift-docs-markdown/hosted_control_planes/hcp-certificates#hcp-custom-cert_hcp-certificates) ## Capabilities for hosted clusters {#hcp-cluster-capabilities_hcp-deploy-non-bm} To reduce resource consumption and prevent unnecessary Operators and operands from being deployed, administrators can enable or disable optional OpenShift Container Platform components when they create a hosted cluster. When capabilities are not specified on a `HostedCluster` resource, the cluster uses the OpenShift Container Platform version’s `DefaultCapabilitySet` settings, excluding the `baremetal` capability. As a result, most optional components are enabled by default. > [!IMPORTANT] > Capabilities are immutable after cluster creation. You cannot change them after you create the `HostedCluster` resource. ### Capabilities that you can enable or disable for a hosted cluster {#hcp-cluster-capabilities-ref_hcp-deploy-non-bm} Familiarize yourself with the supported capabilities that you can enable or disable for a `HostedCluster` resource. The capabilities are described in the following table: | Capability | Description | | --- | --- | | `ImageRegistry` | The OpenShift Image Registry Operator and its operands, including cloud storage infrastructure, such as S3 buckets and Identity and Access Management (IAM) users. | | `openshift-samples` | The OpenShift Samples Operator, which manages example `ImageStreams` and templates. | | `Insights` | The Insights Operator, which collects and uploads cluster telemetry data. | | `baremetal` | The Bare Metal Infrastructure Operator. This capability is excluded from the default set. If needed, you must explicitly enable it. | | `Console` | The OpenShift Web Console Operator and its operands. | | `NodeTuning` | The Node Tuning Operator, which manages node-level performance tuning by using TuneD and performance profiles. | | `Ingress` | The OpenShift Ingress Operator, which manages the default router of the cluster. | The following rules apply when you combine capability settings: No overlap : A capability cannot be in both the `enabled` and `disabled` lists simultaneously. Console requires Ingress : You can disable the `Ingress` capability only if the `Console` capability is also disabled because the console depends on Ingress. Version requirement : You must use OpenShift Container Platform 4.20 or later to disable any of the following capabilities: `openshift-samples`, `Insights`, `Console`, `NodeTuning`, and `Ingress`. You can disable `ImageRegistry` and `baremetal` on versions earlier than 4.20. Bare metal default exclusion : The `baremetal` capability is excluded from the default set. You can add it to the cluster by explicitly enabling it. ### Setting capabilities for a hosted cluster {#hcp-cluster-capabilities-proc_hcp-deploy-non-bm} To reduce unnecessary resource consumption, you can control which optional capabilities are enabled for a hosted cluster when you create the cluster. > [!IMPORTANT] > Capabilities are immutable after cluster creation. You cannot change them after you create the `HostedCluster` resource. You can specify which capabilities are enabled by either using the `hcp` command-line interface (CLI) or by setting the `HostedCluster` manifest. **Procedure** - To specify which capabilities are enabled in a hosted cluster by using the CLI, you can add the `--disable-cluster-capabilities` flag, the `--enable-cluster-capabilities` flag, or both. The following example shows how to disable the `ImageRegistry`, `Console`, and `Ingress` capabilities and enable the `baremetal` capability while you create a hosted cluster on AWS by using the `hcp` command-line interface: ```terminal $ hcp create cluster aws \ --name my-hosted-cluster \ --disable-cluster-capabilities=ImageRegistry,Console,Ingress \ --enable-cluster-capabilities=baremetal ``` You can specify multiple capabilities as a comma-separated list. The supported values are as follows: - `ImageRegistry` - `openshift-samples` - `Insights` - `baremetal` - `Console` - `NodeTuning` - `Ingress` - To specify which capabilities are enabled in a hosted cluster by using the `HostedCluster` manifest at cluster creation time, see the following examples: - To directly disable capabilities in a hosted cluster, add the `spec.capabilities.disabled` section in the `HostedCluster` resource: ```yaml apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: my-hosted-cluster namespace: my-cluster-namespace spec: capabilities: disabled: - ImageRegistry - Console - Ingress # ... ``` - To explicitly enable a capability that is not part of the default set of capabilities, such as the `baremetal` capability, see the following example: ```yaml apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: my-hosted-cluster namespace: my-cluster-namespace spec: capabilities: enabled: - baremetal # ... ``` - You can use both `enabled` and `disabled` if no capabilities are in both lists. See the following example: ```yaml apiVersion: hypershift.openshift.io/v1beta1 kind: HostedCluster metadata: name: my-hosted-cluster namespace: my-cluster-namespace spec: capabilities: enabled: - baremetal disabled: - ImageRegistry - openshift-samples # ... ``` ## Verifying hosted cluster creation on non-bare-metal agent machines {#hcp-non-bm-verify_hcp-deploy-non-bm} After the deployment process is complete, you can verify that the hosted cluster was created successfully. Follow these steps a few minutes after you create the hosted cluster. **Procedure** 1. Obtain the `kubeconfig` file for your new hosted cluster by entering the following command: ```terminal $ oc extract -n \ secret/-admin-kubeconfig --to=- \ > kubeconfig- ``` 2. Use the `kubeconfig` file to view the cluster Operators of the hosted cluster. Enter the following command: ```terminal $ oc get co --kubeconfig=kubeconfig- ``` ```terminal {title="Example output"} NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s ``` 3. View the running pods on your hosted cluster by entering the following command: ```terminal $ oc get pods -A --kubeconfig=kubeconfig- ``` ```terminal {title="Example output"} NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s ```