Description

Background: The current hosted cluster setup allows the addition of DNS names pointing to the API endpoint. However, operational limitations exist, including the automatic generation of KubeConfigs and the static nature of the DNS names used in the console login command. There is a need to enhance flexibility in how DNS names are managed and utilized.

Issue:

1. Static DNS Configuration: DNS names are currently static once the cluster is set up, and changes are not reflected in critical operational tools.
2. KubeConfig Generation: There is no automatic generation of KubeConfigs that incorporate newly added or modified external DNS names.
3. Console Login Command: The command still points to internal DNS names, even if external names are preferred or more relevant based on recent changes.

Objective: Develop a feature that allows dynamic specification and modification of external DNS names at any point (day-0 or post-deployment), with automatic updates to KubeConfigs and console login commands to reflect these changes, enhancing user flexibility and cluster accessibility.

Proposed Enhancements:

1. Dynamic DNS Configuration: Allow users to specify and modify external DNS names at any time during the cluster lifecycle.
2. Automated KubeConfig Updates: Automatically generate and update KubeConfigs to reflect the current external DNS settings, ensuring that users have immediate access to the cluster with the latest configurations.
3. Console Login Adjustments: Update the console login command to dynamically use the latest specified external DNS name.

Additional User Stories

As a self-managed HCP cluster service consumer, I want to be able to:

• Created a hosted cluster with a different external API DNS name than the internal endpoint used for node bootstraps, control plane communication, etc

so that I can

• Replace the user-facing TLS certificate with one from a public CA without breaking control plane functions (i.e. node bootstrap) which are bound to the internal root CA
• Support split-horizon DNS and NAT scenarios
• Ensure a similar UX to standalone control planes where I can use functions such as "Show Login Command" with the correct KubeConfig and DNS configuration

Acceptance Criteria

1. Users can specify and modify external DNS names at cluster creation or at any later point.
2. The system automatically generates and updates KubeConfigs when changes to external DNS names are made.
3. The console login command reflects the latest external DNS names without manual intervention.
4. The feature is tested
5. The feature is documented upstream and downstream