Pod not accessible on NodePort via the Windows 10 host machine.

[willemodendaal]

I'm struggling with Minikube on Windows 10. I have a pod and a service, but the nodePort on the service does not seem to work. When accessing my service using curl I get: curl: (7) Failed to connect to 192.168.49.2 port 31985: Timed out This site can’t be reached

I honestly don't know if this is a Minikube issue, or a Kubernetes issue, or a Skaffold issue, or a plain windows networking issue. Hoping someone can point me in the right direction, and hopefully help folks with a similar issue in future.

Steps to reproduce the issue:

1. Run minikube start (no extra parameters)
2. Use skaffold to run kubectl apply to release pod and service (see yaml below)
3. Try to access pod with curl from within the cluster, it works fine.
4. On the host machine, run minikube service list to get url to the pod.
5. Try to access the pod using curl from the host machine (Windows10), but I get timeouts.

Kubebernetes yaml being applied

I kubectl apply the following to the minikube cluster:

apiVersion: v1
kind: Service
metadata:
  name: doxie-budget-api-svc-local
  labels:
    app: doxie-budget-api-svc
    environment: local
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 80
    nodePort: 31985
    protocol: TCP
  selector:
    app: doxie-budget-api
    environment: local
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: doxie-budget-api-deployment-local
  labels:
    environment: local
    app: doxie-budget-api
spec:
  replicas: 1
  selector:
    matchLabels:
        environment: local
        app: doxie-budget-api
  template:
    metadata:
      labels:
        environment: local
        app: doxie-budget-api
    spec:
      containers:
      - name: doxie-budget-api
        image: doxie-budget-api
        ports:
        - containerPort: 80

Kubectl is definitely pointing to minikube:

The service is running and points to the pod, see endpoint:

I can connect to the pod from within the cluster, no problem:

I can also connect to the pod via the service within the cluster (using the service port):

Minikube shows that the service can be accessed at http://192.168.49.2:31985

But no luck when I access that url from the host machine using curl or the browser:

I tried accessing the same port on the minikube ip for good measure, but no luck either:

I added windows defender firewall rules (both incoming and outgoing) to allow traffic on that port. Not sure what else I can do... can anyone help?

Version information

Minikube:

minikube version: v1.14.0
commit: b09ee50ec047410326a85435f4d99026f9c4f5c4

Kubectl:

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.8", GitCommit:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState:"clean", BuildDate:"2020-08-13T16:12:48Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

Windows:

OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.19041 N/A Build 19041

[tstromberg]

Can you please include the output of the minikube start command? It'd be helpful to know what driver it is using.

[willemodendaal]

Here is the minikube start output:

λ minikube start

• minikube v1.14.0 on Microsoft Windows 10 Pro 10.0.19041 Build 19041
• Using the docker driver based on existing profile
• Starting control plane node minikube in cluster minikube
• Restarting existing docker container for "minikube" ...
• Preparing Kubernetes v1.19.2 on Docker 19.03.8 ...
• Verifying Kubernetes components...
• Enabled addons: storage-provisioner, dashboard, default-storageclass
• Done! kubectl is now configured to use "minikube" by default

[tstromberg]

Does minikube service doxie-budget... do the right thing in this environment by any chance? It should try to open the web browser to the right URL.

I suspect this may be the case of minikube service list listing the wrong URL in the list for the Docker driver, but the minikube service command may still work: https://minikube.sigs.k8s.io/docs/handbook/accessing/#getting-the-nodeport-using-the-service-command -- the reason I suspect this is because the host:port should be on 127.0.0.1 with Docker.

I unfortunately don't have a Windows machine to double-check this with. On macOS with Dockerw, minikube service list doesn't normally show a URL:

|-------------|----------------|--------------|-----|
|  NAMESPACE  |      NAME      | TARGET PORT  | URL |
|-------------|----------------|--------------|-----|
| default     | hello-minikube |         8080 |     |
| default     | kubernetes     | No node port |
| kube-system | kube-dns       | No node port |
|-------------|----------------|--------------|-----|

but minikube service does setup the correct port forward:

minikube service hello-minikubeWed Oct 21 08:54:57 2020
|-----------|----------------|-------------|---------------------------|
| NAMESPACE |      NAME      | TARGET PORT |            URL            |
|-----------|----------------|-------------|---------------------------|
| default   | hello-minikube |        8080 | http://192.168.49.2:32265 |
|-----------|----------------|-------------|---------------------------|
🏃  Starting tunnel for service hello-minikube.
|-----------|----------------|-------------|------------------------|
| NAMESPACE |      NAME      | TARGET PORT |          URL           |
|-----------|----------------|-------------|------------------------|
| default   | hello-minikube |             | http://127.0.0.1:49696 |
|-----------|----------------|-------------|------------------------|
🎉  Opening service default/hello-minikube in default browser...
❗  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

If it doesn't work -- could you check if the instructions from the "Deploy applications" part of https://minikube.sigs.k8s.io/docs/start/ work on your machine?

[willemodendaal]

Minikube tunneling worked fine, but it's not something I want to have to do while developing, so I've switched to plain-old Docker-desktop's built-in Kubernetes instead.

[ManiacDC]

Also having this problem when using the Docker driver with minikube on Windows 10. I can't access the pods exposed via nodeport services.

[tstromberg]

Closing as working-as-intended.

If you need to access a NodePort service, see the instructions on https://minikube.sigs.k8s.io/docs/start/ for your options (kubectl port-forward, minikube service).

[ManiacDC]

NodePort is designed to forward to the host machine. It doesn't "work as intended" unless you simply mean you intend for it to not work. Anyway, not going to push this as I've moved onto another kubernetes implementation that actually works.

[mb250315]

1. minikube service list
2. minikube service --url example-service
   
   --> first command provides the service list and the second commnd will open a port to listen on your windows machine to forward the thigns to minikube node port

[andruwik777]

Also have same problem with accessing pod using curl after exposing port via service.
Tunneling with minikube service works fine but it would be great to have ability to access pod just after "kubectl expose" because it is work on Linux exactly this way (without any additional tunnels). This confuses Windows users during practical task execution in kubernetes tutorials (i.e. I faced this while playing with kubernetes-bootcamp tutorial).

$ minikube version
minikube version: v1.24.0

$ minikube start

• minikube v1.24.0 on Microsoft Windows 10 Pro 10.0.19043 Build 19043
• Using the docker driver based on existing profile
• Starting control plane node minikube in cluster minikube
• Pulling base image ...
• Restarting existing docker container for "minikube" ...
• Preparing Kubernetes v1.22.3 on Docker 20.10.8 ...

P.S.
@tstromberg thank you for workaround with "minikube service" approach, but actually I don't understand why this bug is closed. Seems the problem exists and should be covered for Windows users (to work similar like for the Linux users: Lunux users don't need any additional tunnels with "minikube service" and for them pod is accessible by curl just after "kubectl expose" command). Could you please clarify?

[ekkizogloy]

It seems like the issue is still present. minikube service <service-name> does not work as expected. It opens a browser using the same IP address listed in the above messages 192.168.49.2:<port> and the connection never succeeds.

The port-forward feature does work. kubectl port-forward service/<service-name> <fwd-port>:<service-port>
However there is no reference or dependence to the nodePort value specified in the Service. I expect that the minikube service command would properly forward the traffic to the service's nodePort

> minikube version
minikube version: v1.25.2
commit: 362d5fdc0a3dbee389b3d3f1034e8023e72bd3a7

Output from minikube start

> minikube start         
😄  minikube v1.25.2 on Microsoft Windows 11 Home 10.0.22000 Build 22000
                       ▪ MINIKUBE_ACTIVE_DOCKERD=minikube
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube        
🚜  Pulling base image ...
📌  Noticed you have an activated docker-env on docker driver in this terminal:
         ❗  Please re-eval your docker-env, To ensure your environment variables have updated ports:

        'minikube -p minikube docker-env'


🔄  Restarting existing docker container for "minikube" ...
🐳  Preparing Kubernetes v1.23.3 on Docker 20.10.12 ...
    ▪ kubelet.housekeeping-interval=5m
🔎  Verifying Kubernetes components...
    ▪ Using image kubernetesui/dashboard:v2.3.1
    ▪ Using image kubernetesui/metrics-scraper:v1.0.7
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, dashboard, default-storageclass                                               
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default 

I'm using minikube for local development and testing, and so using the port-forward workaround will work for me, however I have spent a significant amount of time trying to figure this out. Fixing this would save a lot of people a lot of time. Best regards.

[gftea]

Have similar issue, from event log, no matter which service port is allocated, always get the warning of "address already in use"

PS > kubectl expose deployment hello-minikube --type=NodePort --port=8080
service/hello-minikube exposed

PS > kubectl get services hello-minikube
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-minikube NodePort 10.102.215.216 8080:60856/TCP 3s

PS > kubectl get events
LAST SEEN TYPE REASON OBJECT MESSAGE
...
9s Warning listen tcp4 :60856: bind: address already in use node/minikube can't open port "nodePort for default/hello-minikube" (:60856/tcp4), skipping it

PS > minikube service hello-minikube

• Starting tunnel for service hello-minikube.
• Opening service default/hello-minikube in default browser...
  ! Because you are using a Docker driver on windows, the terminal needs to be open to run it.

PS > minikube service list
|-------------|----------------|--------------|---------------------------|
| NAMESPACE | NAME | TARGET PORT | URL |
|-------------|----------------|--------------|---------------------------|
| default | hello-minikube | 8080 | http://192.168.49.2:60856 |
| default | kubernetes | No node port |
| kube-system | kube-dns | No node port |
|-------------|----------------|--------------|---------------------------|

So, the why it still provide the URL with the port which fails to open? and why it always fails to open the TCP port in minikube vm?

[shawinder]

You can simply run minikube service doxie-budget-api-svc-local. It will automatically tunnel it for you and open the deployed app in a browser.

[si-saaref]

Until now 2023.
Still have this similar issue,

I couldn't access NodeIP using docker-driver on windows 10 machine.
Tunneling is worked as well, but i expect to access NodeIP i.e. on 192.168.49.2 with specified port instead of localhost with random port

[hilmeeen]

Hi i get the same issue.

I use service type=NodePort to test the service/pod.
I can't access it with curl via PowerShell or windows browser.

But I can access it with curl via WSL.

[hoglund666]

2024 - Still a problem.

On windows 10, minikube simply refuses to open a port on either 192.168.49.2, 127.0.0.1, or localhost, or 0.0.0.0 w/ the designated nodePort.

Running minikube service servicename indeed starts a subprocess in the command window the preports to 'tunnel', but it does nothing - no ports are opened on any of the above interfaces.

Running netstat -ano verifies that no open ports corresponding to the nodePort or minikube are created on the machine, on any interface.

Port is listening on the pod. Tested.
Running kubectl port-forward pod-name localport:podport works. With this command I am able to connect to the pod.

THIS appears to be a problem with minikube on windows, plain and simple. Honestly I would encourage a re-open of the bug.

FWIW if I am out of bounds here: If tunneling is not supported on windows 10, or nodeports are not supported on windows 10, then please make that clear. If it is supported, then add documentation explaining precisely how to exercise this specific use case, as it's a struggle not just for me but others as well. If this use case is extra problematic on windows 10, for whatever reason, then increase the quality of your log messages so users don't waste two hours fiddling around with inane details just to get a connection to a minikube hosted service. If I may be bold, the current experience borders on ridiculous.

Let me repeat one detail, running minikube service servicename to tunnel is NOT working.
Furthering this last detail: as others have indicated in this thread, running minikube service servicename to tunnel should NOT be a requirement, it should just work, just like it does in linux.

EDIT:

I deleted minikube and switched to the native Kubernetes that ships with Docker Desktop. It works the first time, out of the box, and no extra tunneling step required. The nodePort is opened on the localhost and works.