Dashboard: Document /ui alias breakage on kubernetes 1.6.x

[kallisti5]

Environment

Dashboard version: latest
Kubernetes version: 1.6.7
Operating system: Fedora Atomic 26

The latest documentation mentions going to the following url: (which works under 1.6.7)

• /api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

However, the /ui alias on kubernetes 1.6.7 goes to:

• /api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy/

which results in:
Error: 'malformed HTTP response "\x15\x03\x01\x00\x02\x02"' Trying to reach: 'http://10.244.19.2:8443/'

It's pretty easy to miss the url difference in the documentation vs the older /ui alias. Might want to mention the alias is broken in 1.6.7 after the dashboard https change. (especially since the dashboard is the first container people fire-up on new k8s clusters)

[liggitt]

+1 for documenting

opened https://github.com/kubernetes/kubernetes/pull/53766 to remove the /ui/ redirect and make kubectl cluster-info smarter about the links it generates to include a https scheme if the service port is named https or is port 443

[Deshke]

this is also broken on a 1.7 cluster, where in kubectl cluster-info the dashboard does not even show up

kubectl cluster-info Kubernetes master is running at https://domain.tld Heapster is running at https://domain.tld/api/v1/namespaces/kube-system/services/heapster/proxy KubeDNS is running at https://domain.tld/api/v1/namespaces/kube-system/services/kube-dns/proxy monitoring-grafana is running at https://domain.tld/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy monitoring-influxdb is running at https://domain.tld/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy

[liggitt]

this is also broken on a 1.7 cluster, where in kubectl cluster-info the dashboard does not even show up

not all clusters install the dashboard... if you do the following, what do you see?

kubectl get services -n kube-system -l kubernetes.io/cluster-service=true

[Deshke]

 ~/temp # kubectl get services -n kube-system -l kubernetes.io/cluster-service=true
NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
heapster              ClusterIP   100.67.40.66    <none>        80/TCP          71d
kube-dns              ClusterIP   100.64.0.10     <none>        53/UDP,53/TCP   147d
monitoring-grafana    ClusterIP   100.64.97.110   <none>        80/TCP          41d
monitoring-influxdb   ClusterIP   100.66.2.37     <none>        8086/TCP        71d

 ~/temp # kubectl get deployment -n kube-system -l k8s-app=kubernetes-dashboard
NAME                   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kubernetes-dashboard   1         1         1            1           147d

 ~/temp # kubectl get svc -n kube-system -l k8s-app=kubernetes-dashboard
NAME                   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes-dashboard   ClusterIP   100.65.206.140   <none>        443/TCP   147d

[Deshke]

https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml

also does not add the kubernetes.io/cluster-service=true

[liggitt]

that's why. kubectl cluster-info is not a great pattern, pre-baking label selectors into a command and making assumptions around scheme/port access. if you want a service to appear in the output of that command, it must have that label

[cheld]

The cluster-info flag is used by addon manager to synchronize the manifest files with cluster state. In other words, the flag is only set if addon manager deploys dashboard. If dashboard is manually deployed it cannot be set.

See my comment: https://github.com/kubernetes/dashboard/issues/1849#issuecomment-294100681

I think the behavior is intended to be changed. We could check the status.

[maciaszczykm]

We are aware of this issue. It is mentioned in https://github.com/kubernetes/dashboard/issues/2395.

I have opened https://github.com/kubernetes/kubernetes/pull/53046 to solve it, but it is blocked by https://github.com/kubernetes/kubernetes/issues/53382.

Merging https://github.com/kubernetes/kubernetes/pull/53766 would decrease Dashboard discoverability a lot. Beginners could not find Dashboard easily and use only kubectl and third-party UIs when if it will be done.

[floreks]

We did mention redirect issue in our FAQ. Also in documentation it is stated that major Dashboard version, i.e. 1.6 should equal to major K8S version.

In this case Dashboard 1.6.X should be deployed on K8S 1.6.X where /ui redirect works fine.
In case of Dashboard 1.7.X it should be deployed on K8S 1.7.X where /ui redirect does not work and different URL is mentioned in our Accessing Guide and README.

From what I have checked documentation is correct and does not recommend using /ui redirect when accessing Dashboard 1.7.X

[cheld]

We could stress the difference

[floreks]

Documented in our FAQ: https://github.com/kubernetes/dashboard/wiki/FAQ#ui-redirect-does-not-work-or-shows-error-malformed-http-response

[emwalker]

For anyone running into this issue with v1.8.0, see this link, and if you're using the proxy, try:

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

[cdenneen]

What's the reason the redirect for /ui couldn't just be redirected to the new long URL?
Using kubectl proxy you have to now type/remember the entire URL string vs just allowing /ui to redirect or rely on "bookmarks" and I don't know about everyone else here but bookmarks really become a blackhole of chaos...

[cdenneen]

OK i think i found reasons why the redirect shouldn't be going to the https URL...
Maybe some doc updates for setting up a sample dashboard proxy with Bearer token or something to give n00bs a simple way of getting to dashboard?

[HolimaX]

OK i think i found reasons why the redirect shouldn't be going to the https URL...
Maybe some doc updates for setting up a sample dashboard proxy with Bearer token or something to give n00bs a simple way of getting to dashboard?

Hello, @cdenneen . Could you please share a bit more details on actual 'reason' you have found?

As an example, I have been fighting to get dashboard working and when I did fix the pod creation issue, mentioned in https://github.com/kubernetes/kubeadm/issues/578#issuecomment-519783277 , I was not getting why Chrome is not allowing to access the dashboard and is printing out simple text that I am accessing HTTPS site via HTTP. When I checked, it looked like the certs indeed was not valid, therefore only way to access dashboard is via FireFox. Having this all written, more details would help to understand why weavenet cni plugin is behaving that weirdly and could this behavior be related to it as well.

Thanks.