Support opt-out of node port binding

[jeremylvln]

Is your feature request related to a problem? Please describe.

The players connect to my game servers via a proxy hosted in the same Kubernetes cluster as my game servers. So, internal network routing is sufficient, so the game servers don't need to have a port bound on the node directly. For the sake of strict network topology, I would love to have a way of telling Agones to not bind a not port.

I could avoid specifying the ports field of the GameServer CRD, and add it the the Pod's template directly, however, I have some controllers that are listening to GameServer changes and that are consuming the address and ports fields for internal use. I would prefer to not change that. The only change needed here is to not put the node's IP in the address field but the pod's one instead.

Describe the solution you'd like

One solution would be to add a new portPolicy kind to the GameServer's ports (name TBD, something like PodOnly). When Agones will then reconcile the GameServer, it will simply inject these ports to the Pod's spec and to its status sub-resources.

It will not be breaking for anyone, as this new portPolicy would not be the default. And it can be simple to opt-in or out of this feature.

Describe alternatives you've considered

I can keep the current behavior. My nodes are not exposed directly through Internet so it's not really an issue. However, for the same of clear and optimal network topology, I would love to have at least the choice.

Additional context

N/A

[zmerlynn]

Hmm. The GameServer name matches the Pod name - couldn't you just connect to <GameServer name>:<container port> and rely on DNS? I'm reticent to shoehorn a different policy in for something seemingly that simple.

[jeremylvln]

I don't understand your point. Your solution does not solve any of the issues I raised initially.

Yes, I guess I can directly connect to the server using the pod's IP. However:

1. It still does bind a port to the node, which I want to avoid because I will not use it
2. The GameServer'a status subresource was created with extensibility in mind, so exposing the pod's IP rather than the node one should not be hard

Everything was made to add this feature without hassle, and I find quite interesting to at least give the choice.

I hope I have convinced you :)

[zmerlynn]

It still does bind a port to the node, which I want to avoid because I will not use it

As you mentioned in the first comment, though, you don't have to bind a port to the node at all - you can add a container port to the pod spec and leave the ports array of the GameServer empty (at which point the Agones port policy is irrelevant).

ETA: This looks to be what you did in https://github.com/jeremylvln/Shulker/pull/330

The GameServer'a status subresource was created with extensibility in mind, so exposing the pod's IP rather than the node one should not be hard

I agree that it's not hard to include the pod IP somewhere, but all policies come with a maintenance cost (tests, cross-cutting interactions with other features, etc). In this case you don't even need to know the address, though - you just need the GameServer name (see #2704, which is now GA).

[markmandel]

To get connectivity inside the cluster, does the port need to be defined on the Pod? (I'm actually not sure on this one) -- I had assumed that all Pods could talk to all pods on any port by default? Or is my assumption here incorrect?

I could avoid specifying the ports field of the GameServer CRD, and add it the the Pod's template directly, however, I have some controllers that are listening to GameServer changes and that are consuming the address and ports fields for internal use.

The other option is to store this data on an annotation on the GameServer itself - would that work.

[zmerlynn]

I think this was covered by #3804 / #3807 - please reopen if you disagree!