[RFE] action and/or configs to expose production-grade k8s dashboard

[Pedro Guimarães]

There is no clear way to set up a high-available, secure k8s Dashboard.

If we follow k8s documentation, we can see 2 possible paths [1]:
1) NodePort: As per docs, "This way of accessing Dashboard is only recommended for development environments in a single node setup."
2) kubectl proxy

The problem is that (2) will only be available as long as user has "kubectl proxy" running on the background. It is not an out-of-the-box way to expose dashboard for all customer operations team.
(1) would be more complete, as dashboard is exposed as a service, however it is stated as development env-only solution.

Therefore, can we have a way via charm (actions and/or configs) to set up a Dashboard that is:
- HA
- Secure: SSL or TLS access setup
- Production-grade: we set once for the customer and their operations team can always reach and keep an eye on that dashboard

[1] https://github.com/kubernetes/dashboard/wiki/Accessing-Dashboard---1.7.X-and-above

[George Kraft (cynerva)]

Additional discussion in https://bugs.launchpad.net/charm-kubernetes-master/+bug/1838734

[George Kraft (cynerva)]

We won't be fixing this in kubernetes-master, but as of 1.20, we now provide the option to deploy Kubernetes Dashboard via Juju k8s charms. The docs for this aren't live yet, but they will be here soon: https://ubuntu.com/kubernetes/docs/cdk-addons#kubernetes-dashboard

With the kubernetes-dashboard charm, it should be possible to `juju expose` the application and get a NodePort or LoadBalancer service that is accessible from outside the cluster. However, in my testing, after running `juju expose`, both the k8s-dashboard and kubernetes-dashboard services remained cluster-only (type=ClusterIP). I think there is still work to be done here.

With all that in mind, I'm marking this as Won't Fix for kubernetes-master, but adding this to the new kubernetes-dashboard charm as something to investigate.

[George Kraft (cynerva)]

It looks like I misunderstood what `juju expose` is supposed to do. What it does is create an Ingress resource for the charm, which should be accessible via the kubernetes-worker units on ports 80 and 443.

I think there's a problem with the Ingress resource that gets created, though:

$ curl http:/34.216.138.173.xip.io
Client sent an HTTP request to an HTTPS server.

$ curl -k https:/34.216.138.173.xip.io
Client sent an HTTP request to an HTTPS server.

The k8s-dashboard pods serve HTTPS traffic, but I think nginx-ingress-controller is trying to reach out to it via HTTP, likely because the backend-protocol annotation[1] is not set in the Ingress resource.

[1]: https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#backend-protocol