minikube: `minikube ip` returns 127.0.0.1

Specify a new vm driver instead of none, that would be work. On mac:

minikube start --vm-driver=hyperkit

macOS: minikube is still giving me external ip as 127.0.0.1 (when using minikube tunnel)

• LoadBalancer
• Nginx-Ingress
• minikube ip

is any to fix it? I did read all the comments here

works fine on ubuntu

1. install virtualbox
2. start minikube => minikube start --driver=virtualbox
3. check ip minikube: minikube ip

If you just install minikube on your mac and start minikube you will get IP 127.0.0.1.

The fact that https://minikube.sigs.k8s.io/docs/handbook/accessing/#loadbalancer-access does not have a reference regarding the fact that using --vm-driver=hyperkit is necessary on macOS to have the setup working is unfortunate.

This is what I did on macOS:

minikube start --kubernetes-version=v1.19.4
(In another tab) minikube tunnel
kubectl create deployment hello-minikube1 --image=k8s.gcr.io/echoserver:1.4
kubectl expose deployment hello-minikube1 --type=LoadBalancer --port=8080

This didn’t work and this is following the documentation. Doing it again using --vm-driver=hyperkit (which is not referenced in that documentation page) fixed the issue.

Another fix on top of the documentation one would be to check the vm-driver when running minikube tunnel on macOS as these outputs don’t tell “this is not working” to a new user:

➜  ~ minikube tunnel --help
tunnel creates a route to services deployed with type LoadBalancer and sets their Ingress to their ClusterIP. for a
detailed example see https://minikube.sigs.k8s.io/docs/tasks/loadbalancer

Options:
  -c, --cleanup=true: call with cleanup=true to remove old tunnels

Usage:
  minikube tunnel [flags] [options]

Use "minikube options" for a list of global command-line options (applies to all commands).
➜  ~ minikube tunnel
🏃  Starting tunnel for service hello-minikube1

Came across this several weeks ago when I was running into minikube ip = 127.0.0.1. Never sorted it out, thought I’d give it a shot. Now I’m getting minikube ip = 172.17.0.2 and running into similar issues.

I must be dence because I’m not sorting this out.

• Using WSL2 (Ubuntu 18.04)
• docker, kubectl, minikube, skaffold all in WSL2 (i.e., no Docker for Windows)
• Using --driver=docker because that is the only thing that works in WSL2
• minikube ip is 172.17.0.2
• Can’t connect in browser to 172.17.0.2 as the connection times out
• ingress controller is operating normally for minikube

What do I need to do to get this working?

I think better to update the doc in MiniKube for macOS.

I Google the error for quite a while and it finally brings me here = =

PR opened.

@harlesbayu Yes, I tried that too with using both docker and hyperkit driver. See output below of both:

–driver=hyperkit

minikube service invoiceapi-service --url

Result: http://192.168.64.3:30200

The link above is not reachable as before. Same issue.

---

–driver=docker (default)

minikube service invoiceapi-service --url

🏃  Starting tunnel for service employeeapi-service.
|-----------|---------------------|-------------|------------------------|
| NAMESPACE |        NAME         | TARGET PORT |          URL           |
|-----------|---------------------|-------------|------------------------|
| default   | invoiceapi-service  |             | http://127.0.0.1:51798 |
|-----------|---------------------|-------------|------------------------|
http://127.0.0.1:51798
❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

Result: The link http://127.0.0.1:51798 is not reachable. Same issue.

OS: Windows Minikube: started with Docker Minikube Version: minikube v1.14.0

> minikube service invoiceapi-service

|-----------|---------------------|-------------|---------------------------|
| NAMESPACE |        NAME         | TARGET PORT |            URL            |
|-----------|---------------------|-------------|---------------------------|
| default   | invoiceapi-service | http/9005   | http://192.168.49.2:32575 |
|-----------|---------------------|-------------|---------------------------|
🏃  Starting tunnel for service invoiceapi-service.
|-----------|---------------------|-------------|------------------------|
| NAMESPACE |        NAME         | TARGET PORT |          URL           |
|-----------|---------------------|-------------|------------------------|
| default   | invoiceapi-service |             | http://127.0.0.1:54366 |
|-----------|---------------------|-------------|------------------------| 
🎉  Opening service default/invoiceapi-service in default browser...
❗  Because you are using a Docker driver on windows, the terminal needs to be open to run it.

When I run this command, it automacally open the brower with address ‘http://127.0.0.1:54366/’ but nothing opens. Browser says-- cannot reach to this page.

Any help appreciated.

@abhimjoshi , It’s same if use --driver=hyperkit have you tried minikube service invoiceapi-service --url ?

@srinathganesh1 Nope, no solution at this point. The proposed work around is kubectl port-forward or skaffold --port-forward if you are using that, but it really isn’t a good workaround in development as it will bypass routing issues that will come up in staging and production. At this point, WSL2+kubectl+minikube+docker-driver+nginx-ingress is a no go for local dev is a no go, so I’m still on Ubuntu until it is.

You can also try the nested virtualization route in WSL2, so you can use KVM, but I personally haven’t had luck with it. The Fast Ring has had nested virtualization enabled in the kernel for a while now. Or you can recompile the WSL2 Linux kernel with it enabled. Again, was never able to get it to work properly, maybe you’ll have better luck.

I think we need some integrated ingress similar to docker-proxy or kubectl port-forward.

So that there is some way to deploy an application, and make it available to the world… ? Using NodePort is also something of a hack, when compared to a real LoadBalancer

But it’s definitely a limitation with the current Docker-in-Docker(Desktop) design, that’s for sure.

I think the Docker driver makes much more sense on Linux, where it can access network… So there you can use the docker0 bridge, and it’s almost like a real (err, virtual) k8s node.

Really need to document this, like #4938. Something to include in Documentation Week

This is a design decision (for the docker driver), and not really a bug per se.

@medyagh : can you comment why it uses a tunnel rather than the bridge ?

i.e. 127.0.01 instead of e.g. 172.17.0.2

https://docs.docker.com/network/network-tutorial-standalone/