Support opt-out of node port binding about agones

[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 jeremylvln/Shulker#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.