1. Proposed title of this feature request

HyperShift – Use Management Cluster Ingress for Route Publishing (No HCP Router / LoadBalancer)

Allow HostedCluster to expose control plane services via Route with custom hostnames using only the management cluster’s ingress, without creating the per-HCP router pod and LoadBalancer Service.

Use management cluster ingress for HCP Route publishing (skip HCP router + LB)

2. What is the nature and description of the request?

Today, when a HostedCluster uses Route as the service publishing strategy with custom hostnames for control plane services (APIServer, OAuthServer, Konnectivity, Ignition), HyperShift always creates:

1. A dedicated router deployment (HAProxy) in the HCP namespace that performs SNI-based routing to the backend services.

2. A LoadBalancer Service named `router` (public and/or private, depending on endpoint access) that exposes this HAProxy router.

This design assumes that when customers use custom hostnames (dedicated DNS), they need a dedicated entry point (the HCP router) exposed via LoadBalancer so that external DNS can point to it. There is no option to instead have the management cluster’s ingress (default ingress controller or a sharded one) serve these routes.

Requested change:

Introduce a HostedCluster-level option (e.g. a spec field or annotation such as useManagementClusterIngressForRoutes: true) that, when set and when the relevant services are published via Route (with or without custom hostnames):

1. Do not create the HCP router deployment (HAProxy).
2. Do not create the router LoadBalancer Service (public or private).
3. Do not add the `hypershift.openshift.io/hosted-control-plane` label to the HCP routes (or otherwise mark them for the per-HCP router), so that the management cluster’s default or sharded ingress controller can admit and serve these routes.

When this option is used:

• The control plane operator continues to create the Routes in the HCP namespace (kube-apiserver, oauth, konnectivity, ignition) with the hostnames specified in the HostedCluster spec.
• Traffic to those hostnames is served by whichever management-cluster ingress controller admits the routes (e.g. default router or a sharded controller that selects the HCP namespace via `namespaceSelector`).
• The customer is responsible for ensuring that (a) an ingress controller admits these routes, and (b) DNS for the Route hostnames resolves to that ingress (e.g. the management cluster’s ingress LoadBalancer or the customer’s external LB in front of it).

3. Why does the customer need this? (List the business requirements here)

•  Environments without LoadBalancer support: Customers running HyperShift on-prem or in environments where LoadBalancer services are not provisioned (no cloud LB, no MetalLB) cannot complete HostedCluster creation when using Route publishing with custom hostnames, because the platform creates a `router` LoadBalancer Service that never receives an external IP. Creation stalls until that Service is satisfied. These customers need to use Route + hostnames (e.g., for DNS and TLS) but do not want to introduce a LoadBalancer provisioner solely for this purpose.

• Existing router sharding / dedicated ingress: Customers who already operate a dedicated ingress controller (e.g., via OpenShift router sharding) to serve HCP routes by namespace (or route selector) want traffic to flow only through that controller. They do not need (or want) the HyperShift-managed router pod and its LoadBalancer. Today, they are forced to accept both the extra router + LB and the complexity of pointing DNS to the right place, or to add MetalLB just to satisfy the `router` Service.

• Operational simplicity and cost: A single, shared ingress (management cluster default or sharded) reduces the number of components (no per-HCP router pod, no per-HCP LoadBalancer), simplifies networking and DNS, and in cloud environments avoids extra LoadBalancer cost per hosted cluster.

• Consistency with Route semantics: From the customer’s perspective, “Route” publishing should mean expose via OpenShift Routes; it is not obvious that this implies a dedicated HAProxy + LoadBalancer per HCP. Offering an explicit “use management cluster ingress for these routes” option aligns behavior with customer expectations when they already have ingress capacity on the management cluster.

• Reference case: Customer creates HostedClusters with all services as Route + custom hostnames and a dedicated ingress controller (router sharding by namespace). Install stalled due to the `router` LoadBalancer; they do not support LoadBalancer in their cluster. The workaround was to add MetalLB. The customer requested a way to avoid the router pod and LoadBalancer and use only their ingress controller. Engineering confirmed the current behavior and that an enhancement would be required.

4. List any affected packages or components.

Hosted Control Planes