Port usage and verification

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.

  1. Today, both Gravity and Satellite check the default Kubernetes NodePort range (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”).

  1. 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.

Hi Itay,

I agree with you, the NodePort ports should not be part of the hardcoded installation checks or flag ports bound within the range. This is an easy change, so I’ll PR it soon.

As for rebinding the service ports, I agree with you this is the direction we should head in, but it’s not a set of simple changes so we’re tackling common/known conflicts first (like the vxlan port).

Thanks @knisbet - we have a patched version at the moment for the NodePort issue that we manually place into the produced tar file.

Regarding the other ones - understood. As I mentioned, if you happen to hit a conflict it becomes a blocker, as we have no option of changing it on our end and usually the customer has no option of changing whatever is conflicting on their port.