How to access the Kubeflow dashboard

charm
,
#1

Once you have deployed Kubeflow, it is time to access the Kubeflow dashboard.

1. Get authentication credentials

To display your access credentials, run the following commands:

juju config dex-auth static-username
juju config dex-auth static-password

Empty values here indicate that static username/password authentication is disabled. If you wish to set these values, add the relevant string to the end of the command, e.g.

juju config dex-auth static-username=admin
juju config dex-auth static-password=AxWiJjk2hu4fFga7

2. Find the IP address of the Kubeflow dashboard

To find the IP address of the Kubeflow dashboard for your deployment run:

kubectl get services -n kubeflow

where kubeflow is the name you gave to your Juju model, and hence the namespace of your Kubeflow deployment.

3. Access the dashboard

For local Kubeflow deployments, such as in a workstation, you can simply access the link found in the previous step, appending nip.io, for example: http://10.64.140.43.nip.io.

However, for remote deployments, or running on a virtual machine, creating a SOCKS proxy is required to access the dashboard. This can be done as follows:

  1. Logout from the current session with the exit command

  2. Re-establish connection to the machine using ssh with SOCKS proxy enabled through the -D 9999 parameter. As in the example below:

    ssh -D 9999 ubuntu@<machine_public_ip>

  3. On your computer, go to Settings > Network > Network Proxy, and enable SOCKS proxy pointing to: 127.0.0.1:9999

  4. On a new browser window, access the link given in the previous step, appended by .nip.io, for example: http://10.64.140.43.nip.io

1 Like
How-to Guides
Charmed Kubeflow test
Charmed Kubeflow Documentation
Quick start guide to Kubeflow
#2
#3

Hey Kenneth,

I have applied all of these steps on my own Ubuntu 18.04 system, running Juju on a Kind cluster. I am having some issues with the installation process, and I have noticed that these are reflected in the experiences of others. Perhaps this article is a bit dated and not quite up to the mark on the latest advances?

Anyway, here is the first issue: This Stackoverflow question puts it really well - the ISTIO Ingress Gateway seems to wait forever for the ISTIO pilot to be ready, and this continued for me until I applied the fix suggested in that Stackoverflow answer. However, while this fix did turn the pod green in the Juju status, it did not quite make the pod accessible.

Which brings me to the second issue: you are instructing the user to simply note down the IP address of the kubeflow-dashboard pod and open it using

<ip-address>.nip.io

But this does not work. To access Kubeflow, we need to do so via Kubectl’s port-forwarding, correct? For instance,

kubectl -n kubeflow port-forward svc/kubeflow-dashboard 9092:8082

Will forward it to port 9092, from where you can access it by logging on to localhost:9092.

Secondly, this is not good enough. You can access something like the Kubeflow dashboard, but this is only a hollow likeness which cannot open any of the tabs. To be able to open the jupyter-ui and other tabs on the Kubeflow dashboard, you will need to use the istio-ingressgateway service, to my knowledge.

And that brings me to the third issue: when I run

kubectl -n kubeflow port-forward svc/istio-ingressgateway 9000:80

then I do not get access to the Kubeflow dashboard via the ingress gateway. In fact, I daresay that I only receive a blank page. Perhaps this is because the static username and password authentication has not been registered yet, so I will attempt this again after a reboot.

#4

Hello, Our install guide does mention the need to patch if you’re running RBACs. Please make sure you follow the steps carefully before moving on.

To expose your Charmed Kubeflow environment to users, you can follow this remote access guide - it will be added to our documentation on charmed-kubeflow.io/docs in the coming days.

#5

Changing the system wide config or browser config is challenging usually. If SSH is already available, using sshuttle can make things simpler.

sshuttle -r ubuntu@<machine_public_ip> 10.64.140.43
#6

I don’t think I used it for exactly the same task, but when working a lot with kubeflow deployed on something remote like this I’ve started using a secondary browser that has the proxy settings. So maybe Chrome is my primary browser for doing everything else, and Firefox is my kubeflow browser. There are browser extensions that make managing the proxy settings easier, too.