Comment 4 for bug 2042393

The simple answer is that in it's current state, the placement you selected is unsupported because kubeapi-load-balancer cannot be deployed on any machine that has applications already listening on ports 6443 or 443.

The kubernetes-control-plane charm is coded to tell the load balancer to serve on the same port that it uses itself (6443) for the loadbalancer-internal relation and 443 for the loadbalancer-external relation. So on control plane nodes, both kube-apiserver and the lb end up trying to listen on 6443. The situation is slightly different for the kubernetes-worker, where 6443 is fine but another service is using 443 - namely the ingress-controller, a container running in kubernetes that is part of ckd.

Although the 3 relations you mentioned may result in a deployed bundle, it actually is not configuring load balancing as intended. The intention is that there is load balancing for both internal and external clients that contact the k8s api, and internal and external traffic are separated by port, hence the two relations. This is what happens if, for example, you deploy the load balancer on its own server. The lb serves on 6443 and 443 fronting the control plane nodes (also on 6443), and the resulting relations set the 'kube-control' endpoint for each kube-worker to point to the lb on 6443, rather than using the external port 443.

I will see if I can put together a patch with a config option to allow adjusting either the lb serving ports or the kube-apiserver internal port to avoid this conflict.