minikube node add fails if --ports was given to initial minikube start

[everflux]

What Happened?

I started a single node cluster

minikube start --cpus 4 --memory 16384 --ports 80:80 --driver docker

and wanted to add an additional node afterwards

minikube node add

It uses a different configuration for the added node as the memory shows:

Creating docker container (CPUs=4, Memory=2200MB) ...

The creation fails since port 80 is bound to the first node

stderr:
docker: Error response from daemon: driver failed programming external connectivity on endpoint minikube-m02 (5f7a38f17f200fee0130c69df5aad7f54357fa86e0517d7cb3d08c483504f648): Bind for 0.0.0.0:80 failed: port is already allocated.

It would be great if the added node would not inherit the "--ports" configuration to make this scenario possible.

log.txt

Attach the log file

log.txt

Operating System

Ubuntu

Driver

Docker

[rmsilva1973]

A REALLY crude fix for this could be provided by something like d00178f. But the matter goes deeper than that. If we're running on docker/podman perhaps things like ExposedPorts which are located on the ClusterConfig struct.

As a matter of fact since pods are nodes PERHAPS a few properties could be moved to the node struct:

minikube/pkg/minikube/config/types.go

Lines 84 to 87 in 856c4f2

	ExposedPorts []string // Only used by the docker and podman driver
	ListenAddress string // Only used by the docker and podman driver
	Network string // only used by docker driver
	Subnet string // only used by the docker and podman driver

But I have absolutely no idea on the implcations (or even feaseability) of doing so. I assume addressing #7366 will bump on that. Just my newbie 2 cents. 😊

[rmsilva1973]

/triage discuss

[rmsilva1973]

@spowelljr Sorry if it's not common ettiquete mentioning someone who hasn't commented on an issue (please let me know if it is the case) but since issue 7366 has been around for sometime I thought this could be interesting.

Again: if mentioning maintainers this way is wrong, feel free to tell me so (and please excuse me for doing so)

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[everflux]

/remove-lifecycle stale

[rmsilva1973]

Hey @everflux Do you mind commenting your impressions on my take on this bug? I would like to work on this, but I wanted to bounce ideas with somene more experienced.

[everflux]

I have no idea what the implications of your suggestion are.
When I would use minikube in a scenario as I described above I would expect

• first node uses the exposed ports
• further nodes can't use the ports, as they are in use, so the setting is just ignored

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[everflux]

/remove-lifecycle stale