Recall that minikube is local Kubernetes - it runs a single-node Kubernetes cluster on your personal computer so that you can try out Kubernetes. Now, it doesn't run the Kubernetes cluster in your local box, it runs it inside a VM.

That is why you can't simply access Node IP from your local. Another way to see it is that in Kubernetes you can create NodePort Service to access your workload outside of your cluster but this doesn't work when you are running Kubernetes using minikube - and the reason is the same as mentioned above.

Now, how you work around that is by using minikube service <<YOUR_SERVICE_NAME>> command. This will create a tunnel to access your application - which is exposed using the Service - from outside of the K8S cluster.

You can try minikube tunnel as mentioned by @Hackerman but I have never tried it.

Just to add a bit on top of the previous answer. There is docker bridge limitation that makes it impossible to route the traffic to Linux containers. That is why the minikube tunnel and service were implemented as workaround for that.

minikube tunnel runs as a process, creating a network route on the host to the service CIDR of the cluster using the cluster’s IP address as a gateway. The tunnel command exposes the external IP directly to any program running on the host operating system.

Alternative way to that you may find interesting would be using an ingress which was enabled in #9761 pull request:

.\minikube-windows-amd64.exe addons enable ingress                                                                                           I1121 00:59:39.443965    3000 translate.go:89] Failed to load translation file for en: Asset translations/en.json not found
* After the addon is enabled, please run "minikube tunnel" and your ingress resources would be available at "127.0.0.1"
* Verifying ingress addon...
* The 'ingress' addon is enabled

On your windows system, after the creation of the container that is created by the initial "minikube start", you can see the "minikube instance" by typing "docker ps". This is the minikube 'master' node running in this container.

It would look something like this:

CONTAINER ID   IMAGE                                 COMMAND                  CREATED       STATUS             PORTS                                                                                                                                  NAMES
6293ca0ba5b0   gcr.io/k8s-minikube/kicbase:v0.0.25   "/usr/local/bin/entr…"   2 hours ago   Up About an hour   127.0.0.1:59539->22/tcp, 127.0.0.1:59540->2376/tcp, 127.0.0.1:59537->5000/tcp, 127.0.0.1:59538->8443/tcp, 127.0.0.1:59536->32443/tcp   minikube

In the PORTS column you will see ports that are forwarded by virtue of the way that minikube start the docker container. You can see these kinds of forwards are handled by docker the same as for any contain that you might do a "docker run -p port:port"

Notice that the first port forward in this list is the ssh port: "127.0.0.1:59539->22/tcp".

When you do a "minikube tunnel", minikube will open ssh.exe instances that you can see in your windows task manager if you enable the Command Line display in the column settings.

Those 'tunnels' would look like this:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -N docker@127.0.0.1 -p 59539 -i C:\Users\steve.sims\.minikube\machines\minikube\id_rsa "-L 8080:10.102.174.166:8080"

If I take that command apart and only run this from the command prompt:

ssh docker@127.0.0.1 -p 59539 -i C:\users\steve.sims\.minikube\machines\minikube\id_rsa

Then I get an interactive remote window into the minikube VM (or node). Typing 'ifconfig eth0' I get:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.49.2  netmask 255.255.255.0  broadcast 192.168.49.255

So, indeed my minikube ip is 192.168.49.2, but it is an internal address as the folks above mentioned.

Other than that, the -N parameter on the ssh means "no command" and the -L on the end is the port forward flag in port-to-forward:destination-socket format. Of course, so all of the tunnels are coming across that initial docker -p port:port forward that minikube established when the container was started.

If it is useful, you can create your own ssh instances from that line's format by script and they will work just as well.