add flag for controlling the listen address

[BenTheElder]

we need a way to both allow some users (EG on gitlab CI) to bind to 0.0.0.0:port to the container:api-server and others to (new more secure default?) bind only to localhost. xref #177

this flag could also allow setting a non-random API server port

the design probably needs some more thought

/cc @munnerz
/assign
/kind feature
/priority important-soon

[krisnova]

Can I code this please? Was hoping to have something by ~Friday if possible.

[neolit123]

this flag could also allow setting a non-random API server port
the design probably needs some more thought

exposing even the most useful flag on the CLI, would then leave the question of "why aren't other useful flags exposed too"?

my vote goes for "config only" for everything, networking too.

also kind can support stdin pipes, which renders the argument of "we cannot write temp files in our build, that's why we need flags" invalid.

[BenTheElder]

@kris-nova A PR for this would be most welcome!

---

@neolit123 There definitely is a lower bar to entry for flags though, and it's useful to be able to set eg "name" independently of the config so you can re-use configs.

The listening port seems like the kind of thing you'd want to create many times over with otherwise unique configs.

IMO, the biggest advantage to config is being able to version the format to avoid compatibility problems between releasees, and I don't think the listen address format should ever need to change in an incompatible way (?) (Please suggest why that would be wrong if it is!)

[neolit123]

There definitely is a lower bar to entry for flags though, and it's useful to be able to set eg "name" independently of the config so you can re-use configs

the stdin pipe approach can still be used for this.
not as UX friendly that's for sure.

IMO, the biggest advantage to config is being able to version the format to avoid compatibility problems between releasees, and I don't think the listen address format should ever need to change in an incompatible way (?) (Please suggest why that would be wrong if it is!)

it shouldn't.

something else to note is that kubeadm currently still exposes the --apiserver-advertise-address (and bind port) flags but these make sense only in single-control-plane scenarios. in HA scenarios the ControlPlaneEndpoint in the ClusterConfig should be used instead and that's only available from the config.

i guess my point with this example, there are a lot of useful flags that can be exposed from the CLI, but we decided to draw the line.

[BenTheElder]

In either case I think Kris currently just needs this to be exposed in the library rather than flags etc. -- we can always tweak the flags etc. before the next release. Allowing this to be configured is a no-brainer.

We should probably do:

• default is localhost w/ an ephemeral port assigned
• the address and/or the port can be overridden

---

We should make trade-offs towards UX friendly when they aren't actively harming us to a serious degree, such that kind is easier to use correctly.

Ideally simple usage should not need to dive into config. People want a cluster to integrate against, they're not doing a serious deployment and won't want to dive into our config for simple things like the cluster name.

For kind with HA when that lands, --listen-address would map to the "load balancer" node rather than the actual API servers. Configuring the control plane nodes can be done via config for sure.

Local deployments should probably not be listening on 0.0.0.0 rather than loopback (for security purposes if nothing else, kind really shouldn't be on the public internet!), but EG GitLab CI usage so far seems to depend on it, so this is an important knob to have if we want to fix the default.

[cyriltovena]

Hello there !

Any news on this ? Do you need a hand or @kris-nova got this covered ?

Thanks !

[BenTheElder]

Hi! We're been planning more networking options as part of the v1alpha3 API, I implemented most of it already and have a second PR on the way 😅

[BenTheElder]

this is in config now in #390