Charmed Kubeflow Browser Access (Windows/WSL)

juju
#1

I installed Charmed Kubeflow on WSL. I have WSLg and Chrome from Ubuntu so the Dashboard is working fine.

However, I wonder what should I do if I just want to access from Windows’s web browsers? Normally. I would use localhost and kubectl port-forward setup.

Not sure what to do in the Charmed Kubeflow scenario, as I do not understand what these two lines do

juju config dex-auth public-url=http://10.64.140.43.nip.io
juju config oidc-gatekeeper public-url=http://10.64.140.43.nip.io

Could someone please explain what’s going on and what can I do access Kubeflow from Windows?

#2

When you enable metallb for the IP address range 10.64.140.43-10.64.140.49, you’re giving it that private address range to use. From within the machine running microk8s, 10.64.140.43 is the IP address used to access the frontend. People have run into issues before here if 10.64.140.43 is already a private IP address in use e.g. on a LAN that they’re connected to.

As for configuring the public URLs, it’s just boilerplate config. We’re actually working to remove this manual step. See this GH issue.

In your case, you’re running through WSL. I’m not familiar with this method of running it. But I am familiar with running through a VM with port forwarding and that works. Note that because it’s not localhost, you need to use a SOCKS proxy for forwarding - it’s different than how you forward ports for localhost. See Setup SSH VM Access / Config SOCKS Proxy.

Not sure how that translates to WSL though.

#3

Thanks Colm. Your explanation helps. Based on your notes, I experimented with Windows’ netsh port-proxy, which I believe is the SOCKS equivalent. It is still not working.

10.64.140.43 is available, and is working from Browser launched from within Ubuntu.

10.64.140.43.nip.io

What is the .nip.io is for?

Regardless of Windows env, I guess my confusion stems from the fact that no port number is mentioned in the Charmed Kubeflow instructions. From your SOCKS hint I gathered the port is probably 9999, but seems not.

I looked at the Kubeflow guide it said if no auth is setup, use kubectl port forward, which worked for me in my non-juju install. The juju install is based on Dex auth if I am not mistaken, but tracing the docs to Dex (not specific to Kubeflow) I am confused again.

Is there a port I should try? I also tried 32000…

#4

Hard to answer fully without knowledge of WSL. As for the SOCKS proxy setup between laptop and VM, the 9999 port is the port on the local machine that the proxy listens to. It’s not the destination port. Basically a local server spins up on that port, and all traffic gets diverted through it and then down the SSH tunnel, where it’s forwarded to the VM. Even if you’re browsing the internet, it all goes to the VM when you setup the proxy like that.