validate ports provided by user to --ports flag on docker driver

[magnus-larsson]

Summary

I can’t recreate minikube cluster on WSL2 when using the --ports option to expose ports.
The minikube start command fails on connecting to the various ports that is sets up on the Docker container.

The problem does not occur when I don’t use the --ports option.

Workarounds:

1. Map the ports used by the previous minikube cluster using an extra --ports option, then a new minikube cluster is created.
2. Reboot Windows

Environment

• WSL 2 in Windows 10 1909, 18363.1379
• Ubuntu 20.04
• Docker for Windows 3.1.0
• Minikube 1.17.1

Steps to reproduce the issue:

1. Reboot Windows without any minikube cluster created

2. Create minikube cluster

   minikube start --driver=docker --ports=80:80 --ports=443:443
   

3. Delete the minikube cluster

   minikube delete
   

4. Recreate the minikube cluster and enable logging to see the error

   minikube start --driver=docker --ports=80:80 --ports=443:443 -v=1 --alsologtostderr
   

   The command now reports errors like:

   I0217 11:05:40.014928    3353 main.go:119] libmachine: Error dialing TCP: dial tcp 127.0.0.1:49160: connect: connection refused
   

5. WORKAROUND Need a reliable and low latency local cluster setup for Kubernetes  #1: Recreate the minikube cluster mapping the ports used by the previous minikube cluster

   1. Lookup ports used by minikube

      docker ps
      

      Sample response:

      f73deb28d024   gcr.io/k8s-minikube/kicbase:v0.0.17   "/usr/local/bin/entr…"   About a minute ago   Up About a minute   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 127.0.0.1:49160->22/tcp, 127.0.0.1:49159->2376/tcp, 127.0.0.1:49158->5000/tcp, 127.0.0.1:49157->8443/tcp   minikube
      

   2. Recreate the minikube cluster and map the ports used by the previous minikube cluster

      minikube delete
      minikube start --driver=docker --ports=80:80 --ports=443:443 --ports=49157-49160:49157-49160
      

   Sometimes I have to repeat this procedure a couple of times to get rid of the connection refused error

6. WORKAROUND Support mounting host directories into pods #2: Delete the minikube cluster and reboot Windows

   Trying to avoid this workaround, but sometimes it seems to be the only way out of the problem...

NOTE: Recreating the minikube cluster without the --ports option works without any problem:

These commands can be run multiple times without any errors:

minikube delete
minikube start --driver=docker

[priyawadhwa]

Hey @magnus-larsson thanks for opening this issue, it seems like a bug with our --ports flag. I'm not super familiar with why this would be happening, @medyagh would you have any idea about this?

[magnus-larsson]

We did som more testing yesterday and we noticed that if we map the ports to non system ports (> 1023) it seems to work without any problems. For example, the following command works fine:

minikube start --driver=docker --ports=8080:80 --ports=8443:443

Without root privileges, we should not be able to map to system ports, I guess?

We also tried sudo minikube start --driver=docker --ports=80:80 --ports=443:443, but it results in the error message The "docker" driver should not be used with root privileges.

Since I registered the issue, we have tried out different versions of the WSL kernel, resulting in different error symptoms when mapping to system ports.

So, we guess there is some problem with the error handling somewhere (in WSL, Docker, and/or Minikube...) when trying to map to system ports without sufficient privileges.

Can minikube be enhanced to throw a proper error message when the user tries to map to system ports without sufficient privileges?
I guess that would have helped us avoid mapping to system ports and getting stuck as described above.

[medyagh]

@magnus-larsson that is a great suggestion ! if we provide validation on the ports this will save a lot of other people's time to not debug this !
I wonder if this limitation exists on mac and linux too

I would accept any PR that would do a validation on the ports specified by the user

[MadhavJivrajani]

Hi! I'd like to work on this if possible 😄
/assign

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten