Inconsistent provider behaviour with API server ports

What steps did you take and what happened: [A clear and concise description on how to REPRODUCE the bug.]

A common refrain I have heard from customers:

"As a cluster operator, I may be working in a multi-cloud environment, and also have a directive to always have https endpoints exposed on 443. In the Kubernetes context, this means clients should only ever connect to the API server on port 443."

In Cluster API, we have a number of places where the port can be changed:

• cluster.spec.clusterNetwork.APIServerPort This should be used by infrastructure providers to configure the load balancer port.

• kcp.spec.kubeadmConfigSpec.initConfiguration.localAPIEndpoint.bindPort This will change the port that kube-apiserver will listen on each individual control plane node, and is used by kubeadm

In AWS, CAPA will use cluster.spec.clusterNetwork.APIServerPort to set the LB port and assume kube-apiserver continues to listen on 6443.

In Azure, CAPZ assumes that if cluster.spec.clusterNetwork.APIServerPort isn't 6443, that kube-apiserver is also listening on the different port. This is kind of necessary due to the way the Azure LBs work and the workarounds required for hairpin NAT.

Importantly, in bare-metal / on-prem environments like vSphere/Tinkerbell, we might be using kube-vip to make our control plane highly available. In this circumstance, there is no LB, and cluster.spec.clusterNetwork.APIServerPort is ignored.

What did you expect to happen:

One consistent place.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Enforcing any particular implied behaviour may break one or more providers as well as clusters on upgrade, so should not be done within a v1beta1 release IMO.

Also, not suggesting we change the default port, but make it easier to change the port and have a defined behaviour.

Environment:

• Cluster-api version:
• Minikube/KIND version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug [One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]