Comment 8 for bug 1529760

@XuXinkun,
Thank you for looking into the K8S load balancer. Your suggestion was essentially our initial thought when we implemented the support for load balancer. However, we did not choose this approach because it gets complicated very quickly. The services in K8S are essentially proxy and secondary load balancer for pods, and the set of pods can change any time. This means the members in the pool for the external load balancer needs to be updated accordingly to respond to the change, and the K8S internal modules are best suited for doing this since they manage the services themselves. If we were to implement this in Magnum, we would have to somehow capture all the changes happening in the services and that is very difficult, especially if the user is using the K8S native interface. K8S provides the plugin for OpenStack to do precisely this.

Your concern about managing the password is valid and the current manual approach is a temporary solution to avoid weakening the security in Magnum. The full solution that we are working on is to create an internal service account (trust) with the same privilege as the user; this account and password would be written to the configuration in the master nodes so that K8S can use it to interface with OpenStack. Once this feature is implemented, the user would no longer need to manually enter the password.

Your concern about having to clean up the load balancer is also valid. The normal procedure is to clean up all services in the K8S cluster before deleting the cluster, and this would clean up the Neutron load balancers. But is this step is not taken, then the load balancers would need to be cleaned up manually. A good improvement would be to check for load balancers created for K8S services and clean them up if necessary. If you are interested in this, you are very welcome to write a blueprint and contribute.