Add docs for exposing the dashboard as a service instead of using kubectl proxy

[tvansteenburgh]

From @davecore82.

Some users may want/need access to the dashboard without using kubectl proxy. Document a way to do that.

12:00 <davecore> Do we recommend that our users access the k8s dashboard with kubectl proxy? There seems to be an official way to access the dashboard without kubectl proxy (https://github.com/kubernetes/dashboard/blob/master/docs/user/installation.md).  Do we encourage that? Any thoughts on the dashboard in general?
12:05 <davecore> I wonder if I can just expose the kubernetes-dashboard service with MetalLB that's already deployed
12:16 <tvansteenburgh> davecore: yes we recommend kubectl proxy - see https://ubuntu.com/kubernetes/docs/operations
12:22 <davecore> tvansteenburgh: Thanks Tim. Do we have an alternative for users that can't easily run kubectl proxy on their machines? My current deployment at customer site has access to the environment via a Citrix virtual desktop. They can use putty to SSH to the ubuntu server where kubectl is installed.    I'm thinking of 2 possibilities:   1) find a way to run kubectl proxy from windows and use kubectl proxy    or 2)  expose the dashboard (maybe with metalLB?) and 
12:22 <davecore> access it from any web browser
12:22 <davecore> Any thoughts about that use case?
12:24 <tvansteenburgh> davecore: either of those should work
12:25 <davecore> tvansteenburgh: thanks.  is there any chance we could have an official recommended way from the k8s team to use metallb to do that?

[evilnick]

Okay, yes, I see how that could work

[kwmonroe]

If you can access either the kubeapi-load-balancer or kubernetes-master IP addresses, you can just hit the dashboard url directly:

https://<$IP:$PORT>/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Note, the kubeapi-l-b is exposed and listens by default on port 443. k8s-master is not exposed by default and listens on port 6443.

[davecore82]

We don't have kubeapi-load-balancer in this deployment, but we have MetalLB.

Here's how I ended up doing it:

Exposing the dashboard service and adding the SSL certificate.

Start by changing the kubernetes-dashboard service spec type from clusterIP to Loadbalancer:

$ kubectl edit svc -n kubernetes-dashboard kubernetes-dashboard

spec:
  clusterIP: 192.152.183.75
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32298
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    k8s-app: kubernetes-dashboard
  sessionAffinity: None
  type: LoadBalancer

You must then add the SSL certificate and key to the kubernetes-dashboard-certs secret:

$ kubectl edit secret -n kubernetes-dashboard kubernetes-dashboard-certs

apiVersion: v1
data:
  <key filename>: <the actual SSL key data>
  <cert filename>: <the actual SSL certificate data> 
kind: Secret
metadata:
  annotations:
[...]

Finally you need to remove --auto-generate-certificates and ad --tls-cert-file and --tls-key-file to the kubernetes-dashboard deployment:

$ kubectl edit deploy -n kubernetes-dashboard kubernetes-dashboard

[...]
    spec:
      containers:
      - args:
        - --auto-generate-certificates
        - --tls-cert-file=<cert filename>
        - --tls-key-file=<key filename>
[...]

You should then be able to access the dashboard via HTTPS at the public IP of the service:

$ kubectl get svc -n kubernetes-dashboard kubernetes-dashboard

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)         AGE
kubernetes-dashboard   LoadBalancer   192.152.183.75   10.109.12.32   443:32298/TCP   13d

To avoid getting an invalid SSL certificate error in Chrome, the Chrome browser should trust the issuing CA.