Process and Automation for Migrating the External IP of the Hosted Control Plane's Kube-APIServer LoadBalancer Service

The kube-apiserver LoadBalancer service for a Hosted Control Plane (HCP) cluster relies on a specific external IP address provided by an infrastructure Load Balancer (e.g., MetalLB, bare-metal router, F5, etc.). This IP is the single most critical endpoint for the cluster.
There is currently no documented, safe, or automated procedure to change only this external IP address, regardless of the Load Balancer provider.
A manual attempt to change the service's external IP or the underlying Load Balancer configuration risks a catastrophic failure because:
The IP change must be reconciled across internal components managed by the HyperShift Operator and the underlying Load Balancer Operator (like MetalLB).
The Kubelet configuration on all worker nodes (data plane) must be updated instantly and safely to point to the new API server IP.
Failure to synchronize these updates results in the worker nodes being unable to contact the API server, causing the cluster to become unresponsive and potentially unrecoverable.
The request is to develop and document a simple, operator-driven workflow to safely migrate the single, dedicated external IP address used by the kube-apiserver LoadBalancer service in a HyperShift environment.
The process must be provider-agnostic where possible, and specifically address the following necessary reconciliations:
Orchestrated IP Update: The process must coordinate the change of the external IP assignment in the Load Balancer configuration (e.g., updating the MetalLB AddressPool or an equivalent provider resource).
Operator-Managed Transition: Ensure the HyperShift Operators manage the transition of the kube-apiserver LoadBalancer service from the old IP to the new IP.
Kubelet Configuration Update: The process must automatically update the Kubelet configuration on all worker nodes (data plane) to reference the new API server IP address without requiring manual intervention, new MachineConfigs, or a reboot of the worker nodes.
The final procedure should be as simple and robust as the documented CNI migration steps (SDN to OVN) for HCP, requiring minimal user interaction.

The inability to safely change this single critical IP address imposes severe operational constraints, restricting a customer's ability to perform necessary networking changes, migrations, or recovery steps in a highly available and critical Hosted Control Plane environment.