In-cluster clients should be able to talk directly to the node local apiservert ip address and as a best practice should all be configured to use it. This load balancer provides added benefit in cloud environments of healthchecking the path from the machine to the load balancer fronting the kube-apiserver. It becomes more cruicial in baremetal/on-prem environments where there may not be a load balancer and instead just 3 unique endpoints directly to redundant kube-apiservers. In this case: if using just dns: intermittent traffic failures will be experienced if a control plane instance goes down. Using the node local load balancer: there will be no traffic disruption

    4.16

    100%

    1. Schedule a pod on any hypershift cluster node
    2. In the pod run curl -v -k https://172.20.0.1:6443
    3. The verbose output will show that the kube-apiserver cert does not have the node local client load balancer IP address in it's IPs section and therefore will not allow valid HTTPS requests on that address
    

    Secure HTTPS requests cannot be made to the kube-apiserver

     Secure HTTPS requests can be made to the kube-apiserver (no need to run -k when specifying proper CA bundle)