42

Kubernetes newbie (or rather basic networking) question: Installed single node minikube (0.23 release) on a Ubuntu box running in my LAN (on IP address 192.168.0.20) with VirtualBox.

minikube start command completes successfully as well:

minikube start
Starting local Kubernetes v1.8.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...
Kubectl is now configured to use the cluster.

minikube dashboard also comes up successfully (running on 192.168.99.100:30000).

What I want to do is access minikube dashboard from my MacBook (running on 192.168.0.11) in the same LAN.

Also I want to access the same minikube dashboard from the internet.

For LAN Access

Now from what I understand I am using VirtualBox (the default vm option), I can change the networking type (to NAT with port forwarding) using vboxnet command

VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,,22"

as listed here

In my case it will be something like this

VBoxManage modifyvm "VM name" --natpf1 "guesthttp,http,,30000,,8080"

Am I thinking along the right lines here?

Also for remotely accessing the same minikube dashboard address, I can setup a no-ip.com like service. They asked to install their utility on Linux box and also setup port forwarding in the router settings which will port forward from host port to guest port.

Is that about right? Am I missing something here?

informatik01
  • 16,038
  • 10
  • 74
  • 104
Robin Bajaj
  • 2,002
  • 4
  • 29
  • 47
  • 1
    I am looking for an answer to this question, so if you succeeded in setting this up and forgot to self-answer, please revisit. – Tomáš Hübelbauer Nov 27 '17 at 22:29
  • I tried `kubectl proxy` and replacing `localhost` with the local network IP of the host where `minikube` is running but it doesn't seem to be listening on all interfaces, just localhost. I don't run a graphical interface on that host so I'd really like to be able to access it from the outside. – Tomáš Hübelbauer Nov 27 '17 at 22:33

10 Answers10

70

I was able to get running with something as simple as:

kubectl proxy --address='0.0.0.0' --disable-filter=true
Jeff Prouty
  • 709
  • 5
  • 4
  • 1
    Why do you need to use `--disable-filer=true`? – Murmel Nov 10 '20 at 18:58
  • see hao's answer for an explanation – mit Jan 01 '21 at 23:02
  • The docs link hao's provided has moved. The command `kubectl proxy --help` shows the following: --disable-filter=false: If true, disable request filtering in the proxy. This is dangerous, and can leave you vulnerable to XSRF attacks, when used with an accessible port. – Keehl Mar 26 '21 at 11:35
40

@Jeff provided the perfect answer, put more hints for newbies.

  1. Start a proxy using @Jeff's script, as default it will open a proxy on '0.0.0.0:8001'.

    kubectl proxy --address='0.0.0.0' --disable-filter=true
    
  2. Visit the dashboard via the link below:

    curl http://your_api_server_ip:8001/api/v1/namespaces/kube-system/services/http:kubernetes-dashboard:/proxy/
    

More details please refer to the official documentation.

pzkpfw
  • 565
  • 3
  • 21
hao
  • 1,144
  • 12
  • 15
  • 2
    I'm not sure if it's a recent change, but for me (using Minikube v1.12.1, Kubernetes v1.18.3) the dashboard namespace is kubernetes-dashboard, so the url would use: ... /api/v1/namespaces/kubernetes-dashboard/services ... – Xeozim Jul 30 '20 at 08:21
  • 1
    @Xeozim, according to your url, your dashboard was installed under namespace `kubernetes-dashboard` but not `kube-system`. – hao Aug 02 '20 at 14:45
  • @hao I used `minikube dashboard` to create it so I assume that's what it defaults to now? – Xeozim Aug 05 '20 at 09:19
  • Same as for Jeff: Why do you need the `--disable-filter=true` flag? – Murmel Nov 10 '20 at 18:59
  • 2
    without `--disable-filter=true` ,you cannot access. And on that time, you should set something like this `--accept-hosts=^192\.168` to allow some addresses to access. – Jess Chen Apr 13 '21 at 05:07
  • To leave filter on, you can specify your GCE vm instance's external IP here with --accept-hosts='35.246.xx.xx' . It's external here, because kube-proxy faces commutication through the CE bastion host. – Dr. Alexander Jul 14 '22 at 07:10
36

I reached this url with search keywords: minikube dashboard remote. In my case, minikube (and its dashboard) were running remotely and I wanted to access it securely from my laptop.

[my laptop] --ssh--> [remote server with minikube]

Following gmiretti's answer, my solution was local forwarding ssh tunnel:

On minikube remote server, ran these:

minikube dashboard
kubectl proxy

And on my laptop, ran these (keep localhost as is):

ssh -L 12345:localhost:8001 myLogin@myRemoteServer

The dashboard was then available at this url on my laptop:

http://localhost:12345/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

S2L
  • 1,746
  • 1
  • 16
  • 20
26

The ssh way

Assuming that you have ssh on your ubuntu box.

First run kubectl proxy & to expose the dashboard on http://localhost:8001

Then expose the dashboard using ssh's port forwarding, executing:

ssh -R 30000:127.0.0.1:8001 $USER@192.168.0.20

Now you should access the dashboard from your macbook in your LAN pointing the browser to http://192.168.0.20:30000

To expose it from outside, just expose the port 30000 using no-ip.com, maybe change it to some standard port, like 80.

Note that isn't the simplest solution but in some places would work without having superuser rights ;) You can automate the login after restarts of the ubuntu box using a init script and setting public key for connection.

  • Can you please flesh this answer out? I ran `kubectl proxy &` on the Ubuntu Server host and `ssh -R …` on the Mac and connected to it, but accessing `{ubuntuServerHostLocalIp}:30000` didn't work. Do I have it right? – Tomáš Hübelbauer Dec 01 '17 at 19:12
  • 1
    `kubectl` and `ssh` should be run in Ubuntu so you route localhost:8001 to 192.168.0.20:3000 (if 192.168.0.20 is ubuntu box ip address). In this case, you're opening an internal port as an open port on the same computer. (Yep, you're creating an ssh connection inside your computer, just for routing) More about ssh magic [here](https://blog.trackets.com/2014/05/17/ssh-tunnel-local-and-remote-port-forwarding-explained-with-examples.html). This will be port forwarding. – Gabriel Miretti aka gmiretti Dec 02 '17 at 02:49
  • 1
    I misunderstood `kubectl proxy` originally, turns out one is supposed to run that on the host where they want to see the dashboard at. That said when running on master node, SSH proxying is indeed a solution. https://github.com/kubernetes/dashboard/issues/692 was very helpful to me. – Tomáš Hübelbauer Dec 02 '17 at 09:07
8

I had the same problem recently and solved it as follows:

  1. Get your minikube VM onto the LAN by adding another network adapter in bridge network mode. For me, this was done through modifying the minikube VM in the VirtualBox UI and required VM stop/start. Not sure how this would work if you're using hyperkit. Don't muck with the default network adapters configured by minikube: minikube depends on these. https://github.com/kubernetes/minikube/issues/1471
  2. If you haven't already, install kubectl on your mac: https://kubernetes.io/docs/tasks/tools/install-kubectl/
  3. Add a cluster and associated config to the ~/.kube/config as below, modifying the server IP address to match your newly exposed VM IP. Names can also be modified if desired. Note that the insecure-skip-tls-verify: true is needed because the https certificate generated by minikube is only valid for the internal IP addresses of the VM.

    clusters:
    - cluster:
        insecure-skip-tls-verify: true
        server: https://192.168.0.101:8443
      name: mykubevm
    contexts:
    - context:
        cluster: mykubevm
        user: kubeuser
      name: mykubevm
    users:
    - name: kubeuser
      user:
        client-certificate: /Users/myname/.minikube/client.crt
        client-key: /Users/myname/.minikube/client.key
    
  4. Copy the ~/.minikube/client.* files referenced in the config from your linux minikube host. These are the security key files required for access.

  5. Set your kubectl context: kubectl config set-context mykubevm. At this point, your minikube cluster should be accessible (try kubectl cluster-info).

  6. Run kubectl proxy http://localhost:8000 to create a local proxy for access to the dashboard. Navigate to that address in your browser.

It's also possible to ssh to the minikube VM. Copy the ssh key pair from ~/.minikube/machines/minikube/id_rsa* to your .ssh directory (renaming to avoid blowing away other keys, e.g. mykubevm & mykubevm.pub). Then ssh -i ~/.ssh/mykubevm docker@<kubevm-IP>

AndyB
  • 131
  • 2
  • 3
  • for this line, "insecure-skip-tls-verify: true", what if I still want use the verify? Is there any solutions that I can regenerate the ca.crt based in the new ip? – MarcuX Sep 03 '19 at 08:51
  • 1
    It should be possible, but you'd need to find the minikube private key to create a new certificate. I haven't tried yet. – AndyB Sep 04 '19 at 09:11
3

Thanks for your valuable answers, If you have to use the kubectl proxy command unable to view permanently, using the below "Service" object in YAML file able to view remotely until you stopped it. Create a new yaml file minikube-dashboard.yaml and write the code manually, I don't recommend copy and paste it.

apiVersion : v1
kind: Service
metadata:
  labels:
    app: kubernetes-dashboard
  name: kubernetes-dashboard-test
  namespace: kube-system
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9090
    nodePort: 30000
  selector:
    app: kubernetes-dashboard
  type: NodePort

Execute the command,

$ sudo kubectl apply -f minikube-dashboard.yaml

Finally, open the URL: http://your-public-ip-address:30000/#!/persistentvolume?namespace=default

Lakshmikandan
  • 4,301
  • 3
  • 28
  • 37
1

Slight variation on the approach above.

I have an http web service with NodePort 30003. I make it available on port 80 externally by running:

sudo ssh -v -i ~/.ssh/id_rsa -N -L 0.0.0.0:80:localhost:30003 ${USER}@$(hostname)

user553965
  • 1,199
  • 14
  • 15
1

Jeff Prouty added useful answer:

I was able to get running with something as simple as:

kubectl proxy --address='0.0.0.0' --disable-filter=true

But for me it didn't worked initially.

I run this command on the CentOS 7 machine with running kubectl (local IP: 192.168.0.20).

When I tried to access dashboard from another computer (which was in LAN obviously):

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

then only timeout was in my web browser.

The solution for my case is that in CentOS 7 (and probably other distros) you need to open port 8001 in your OS firewall.

So in my case I need to run in CentOS 7 terminal:

 sudo firewall-cmd --zone=public --add-port=8001/tcp --permanent
 sudo firewall-cmd --reload

And after that. It works! :)

Of course you need to be aware that this is not safe solution, because anybody have access to your dashbord now. But I think that for local lab testing it will be sufficient.

In other linux distros, command for opening ports in firewall can be different. Please use google for that.

Community
  • 1
  • 1
sobczak.dev
  • 973
  • 7
  • 11
0

Wanted to link this answer by iamnat.

https://stackoverflow.com/a/40773822

  1. Use minikube ip to get your minikube ip on the host machine
  2. Create the NodePort service
  3. You should be able to access the configured NodePort id via < minikubeip >:< nodeport >

This should work on the LAN as well as long as firewalls are open, if I'm not mistaken.

Dr. Chocolate
  • 2,043
  • 4
  • 25
  • 45
0

Just for my learning purposes I solved this issue using nginx proxy_pass. For example if the dashboard has been bound to a port, lets say 43587. So my local url to that dashboard was

http://127.0.0.1:43587/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/

Then I installed nginx and went to the out of the box config

sudo nano /etc/nginx/sites-available/default

and edited the location directive to look like this:

    location / {
        proxy_set_header Host "localhost";
        proxy_pass http://127.0.0.1:43587;
    }

then I did

sudo service nginx restart

then the dashboard was available from outside at:

http://my_server_ip/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/#/cronjob?namespace=default
Sodu Parsiev
  • 61
  • 1
  • 4