Publish additional ports and IPs when running minikube start

[arielmoraes]

When minikube start command runs using the Docker driver it tells Docker to publish some ports, but it binds to the localhost ip only, thus not giving a chance to access the cluster from another machine using the kubectl for example. Another issue is if one wants to access a Service via an Ingress, in that case we need the same solution, which is to add some entries to the iptables as following:

iptables -I DOCKER-USER 1 ! -i docker0 -o docker0 -p tcp -j ACCEPT -d $(minikube ip) --dport 443
iptables -t nat -A DOCKER ! -i docker0 -p tcp -j DNAT --dport 443 --to-destination $(minikube ip):443

I could also execute those command to bind the 8443 port to 0.0.0.0 to use the kubectl outside the local minikube machine.

Does minikube provide a better way of doing that or is that an inexistent feature?

[afbjorklund]

When minikube start command runs using the Docker driver it tells Docker to publish some ports, but it binds to the localhost ip only, thus not giving a chance to access the cluster from another machine using the kubectl for example.

This is by design. The minikube cluster is not supposed to be available "outside" the local developer machine, currently the recommended approach is to ssh into the minikube host if wanting remote access. This goes for all the drivers, not only docker.

There actually two different issues here, the first is accessing the apiserver remotely (for some reason). Typically kubectl proxy. The other is making a deployed application available remotely, typically kubectl port-forward (or perhaps a proper ingress)

This probably need some better explaining in documentation.

Because it is a recurring question (and perhaps expectation)

Similar to: #8008 #8398

Requesting people to set up tunnels does not improve security.

[afbjorklund]

The currently exposed ports are:

• 22 for ssh (tunneled)
• 2376 for old docker
• 8443 for apiserver
• 5000 for registry hack

There is a pending request to make it possible for the user to add more (#7332), but that doesn't really answer the question...

We probably don't need to expose docker anymore, and the registry port is just to get around the TLS certificate requirement.

1. DOCKER_HOST=ssh://USER@HOST:PORT
2. https://docs.docker.com/registry/deploying/

Currently we use ssh through a local tunnel, but it is also listening on the node directly. Maybe should be on loopback only ?

[arielmoraes]

I think the main reason that is asked a lot is because minikube is a very easy way of starting a new k8s cluster. So some people will want to use it as a "home cluster" which gives the possibility to host some small applications, like an DLNA server etc. Thus going beyond of just a developer cluster.

Now for the design part, I think it would be nice to leave the decision of which ports to expose to the user, that would close all those issues, wouldn't it? 😄

[afbjorklund]

I think the main reason that is asked a lot is because minikube is a very easy way of starting a new k8s cluster.

One could also view this as saying that kubeadm is too complicated, so people turn to minikube for some help ?

It would be nice to cooperate a bit more, so that there are available alternatives for both development and deployment.
There should be an easy path to follow, how to start with containers and images and move on to orchestration and clusters.
But it also quickly becomes associated with particular vendors and cloud providers. And it is hard to please multiple audiences.
Both running kubeadm locally (with the none driver) and exposing it externally are popular options, whether we "like it" or not...

• https://github.com/kubernetes/community/tree/master/sig-cluster-lifecycle (kubeadm, minikube)
• https://github.com/kubernetes/community/tree/master/sig-testing (kind)

[tstromberg]

Discussed with team, it seems like we would be willing to accept a PR that introduces this functionality.

[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-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

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

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.