There are two port-related topics I’d love some comments on. I wasn’t sure if these were best to be GitHub issues or here, so I put them here.
- Today, both Gravity and Satellite check the default Kubernetes
NodePortrange (30000-32767), and ensure that nothing is bound on the host machine on that port. This is not really useful for a couple of reasons:
a. Gravity allows you to change that range for a given installation, so having it hardcoded seems meaningless.
b. Kubernetes is smart enough to not bind to ports that are already bound within that range, so by preventing installation due to a conflict there is not helpful.
Specifically, we had a customer who had SumoLogic running on their machine which binds to ports 31000 and 32000 and we couldn’t install Gravity because of this. The usage of those ports is not a blocking problem because Kubernetes would just not bind to those ports anyway.
The ideal resolution here is to just remove this specific check from both Gravity and Satellite so that it no longer blocks installations (or at least make it “info” rather than “error”).
- The list of ports for Gravity is quite extensive, and the chances it does not conflict with any other program on a given machine is not high. For example, many monitoring programs could be running and bound to a port that Gravity is using.
Today, Gravity lets you change some ports (e.g. VXLAN, or DNS, though the latter is broken). However, many other ports are unchangeable, meaning that Gravity cannot be installed on those machines. Since we can’t tell customers to not run their own software on their machines, it presents a challenge for us.
The ideal resolution here is that every port in Gravity is configurable, and that the preflight validation respects the configuration when running. This should be easily specifiable in cluster-config.yaml.