Allow to specify the port of the api servers

[JrCs]

Allow to specify another port than 443 for the API servers.
For example kubeadm use the port 6443 instead of 443.

[dghubble]

Thanks for the suggestion.

I don't see the case for this. Can you propose this to upstream bootkube to see if its something they care to support? That might lend it some precedent.

The current setup is best practice at the moment, as far as I'm aware.

[JrCs]

Actually we can specify the port of the API with bootkube using the --api-servers option.
The difference with the bootkube-terraform is that the api_servers variable is NOT a list of URLs (with host:port) but only a list of nodes or ips.
If we want to be like upstream bootkube, we need to change api_servers variable to a list of URLs. I can propose a PR for that is you are ok.
About the use case, listening the api on other port than 443 allow to keep the port free to be use by an http server for example. Here the PR about kubeadm: kubernetes/kubernetes#34719

[JrCs]

New PR done: #18
Now bootkube-terraform have the same behavior than bootkube

[dghubble]

Looks like bootkube is allowing this. Its a little concerning, because we don't test this and higher-level projects are always using 443.

Its fine if kubeadm wants to change their default port, but I don't plan to change the default here. As for whether customization should be permitted, for now I think it should not be. In the kubeadm issue you link, the only concrete use-case I see is "ingress controller on a single node cluster, that was one of the main arguments". That's targeting a dev cluster usage and changing the taint setup to allow workloads to be run on controllers (since its all they've got). If we were to add it, higher-level projects then have to consider permitting it as well, and adjusting firewall policies or ingress setups).

I'm not keen to add an addition variable, allow this to vary between clusters, change (break) the current api_servers definition, or have regex's in there. I'd still recommend everyone choose 443 and don't see accommodating those odd use cases as worth disruption or breakage. tbh, I'm surprised kubeadm merged that.

[dghubble]

Perhaps there are more legitimate use-cases that haven't been voiced. Perhaps if there were sufficient reason for the whole Kubernetes ecosystem to change, then all poseidon projects could switch (all firewalls and load balancers, across all platforms) in unison so all platforms continue to "just work" and it remains an implementation detail. It'll still need all sorts of breakage notices, I'm thinking of all the load balancers and routers I'd need to update. It'd be rather disruptive, but if it was clearly the future direction...

[JrCs]

Ok i understand your explainations.

[dghubble]

This would be a non-breaking way to introduce the option, and more likely than #18. If running the apiserver on 6443 gains wide adoption we could make the switch, re-open this as an escape hatch (in case someone can't switch to 6443 for a time), and then remove it once 6443 is canonical.