Feature Description

Hosted Control Planes using LoadBalancer service publishing strategies face critical limitations in managing LoadBalancer service in both, initial deployment (Day 1) and ongoing operations (Day 2):

• Cannot control IP address pool selection when multiple pools exist

• Cannot specify well-known IP addresses for DNS and network planning

• Cannot configure provider-specific LoadBalancer settings

These limitations create operational constraints, prevent proper network planning, and introduce significant risk when network changes are required.

Day 1 Problems - Initial Deployment

When creating hosted clusters with LoadBalancer service publishing strategies, users currently cannot:

•  Control IP Address Pool Selection: In environments with multiple LoadBalancer IP address pools (e.g., MetalLB AddressPools), the HyperShift operator cannot be directed to use a specific pool. This prevents proper network segmentation, resource allocation, and compliance with organizational IP address management policies.
• Specify Well-Known IP Addresses: Users cannot designate specific IP addresses for LoadBalancer services during cluster creation. This prevents establishing DNS records with predictable, well-known API server endpoints, which is essential for network planning, firewall rules, certificate management, and integration with external systems.
• Configure LoadBalancer Provider Settings: The HyperShift operator does not expose mechanisms to configure provider-specific LoadBalancer settings that may be required for complex network topologies or specific infrastructure requirements.

These limitations force users into reactive network management, where IP addresses are assigned arbitrarily and must be discovered post-deployment, complicating DNS configuration, security policies, and operational procedures.

Day 2 Problems (Operational Lifecycle)

After a hosted cluster is deployed, users face severe constraints when network changes are required:

• No Safe IP Migration Capability: There is currently no documented, safe, or automated procedure to change the external IP address of the kube-apiserver LoadBalancer service. This single IP address is the most critical endpoint for the cluster, and the inability to migrate it safely creates significant operational risk.
• Catastrophic Failure Risk: Manual attempts to change LoadBalancer IP addresses risk catastrophic cluster failure because:
• The IP change must be coordinated across multiple systems: the LoadBalancer provider configuration (e.g., MetalLB AddressPool), the HyperShift operator's reconciliation of the LoadBalancer service, and the kubelet configuration on all worker nodes.
  • Failure to synchronize these updates results in worker nodes being unable to contact the API server, causing the cluster to become unresponsive and potentially unrecoverable.
  • There is no operator-driven workflow to ensure safe, coordinated transitions.
• Operational Constraints: The inability to safely change LoadBalancer IP addresses prevents necessary networking changes, migrations, recovery operations, and compliance with evolving network policies in highly available, critical Hosted Control Plane environments.

Additional Details

The HyperShift operator currently manages LoadBalancer services created through service publishing strategies without exposing sufficient control mechanisms for users to:

• Influence IP address selection during cluster creation
• Safely coordinate IP address changes across all affected components during cluster operations
• Ensure proper synchronization between LoadBalancer provider configuration, service state, and worker node kubelet configuration

Impact

These limitations impose severe operational constraints that:

• Prevent proper network planning and IP address management
• Block DNS integration with predictable endpoints
• Create compliance challenges with organizational IP address policies
• Introduce significant risk when network changes are required
• Restrict the ability to perform necessary networking migrations or recovery operations
• Impact the reliability and maintainability of Hosted Control Plane deployments

Scope

The solution should be provider-agnostic where possible, supporting various LoadBalancer providers (MetalLB, AWS Load Balancer Controller, bare-metal routers, F5, etc.) while ensuring safe, automated coordination of IP address changes across the entire Hosted Control Plane infrastructure.