User Story

As an OpenShift developer I want cluster-api-provider-azure (CAPZ) to support both an internal and external API server load balancer so that there is feature parity between upstream CAPZ and OCP's existing support.

<Describes high level purpose and goal for this story. Answers the questions: Who is impacted, what is it and why do we need it?>

Background

Using the Terraform-based installer and MAPI, OCP supports two API server endpoints - one prefixed with `api` for the external endpoint, and one prefixed with `api-int` for the internal endpoint.

The installer team has a workaround via CORS-3270 that creates an internal load balancer not managed by CAPZ, but this is not considered a desirable long term state.

<Describes the context or background related to this story>

Steps

• Work with CAPZ maintainers to approve a design for their upstream issue (https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/4755)
• Implement code that provides an external endpoint for private clusters

Stakeholders

• OCP developers standardizing on Cluster API as a way of managing cloud resources.

Definition of Done

• CAPZ clusters can be installed with two API server endpoints, one internal and one external, that both accept ingress and egress traffic.
• Upstream unit tests and end-to-end tests are added to cover the new implementation.

• Docs

• None - this is an implementation parity concern that does not affect components that we expect users to interact with.

• Testing

• As this is an upstream project, unit tests and end-to-end tests should be included to confirm the functionality of the endpoints.