Move SDK server code from pkg/gameservers to a separate package

[jkowalski]

Right now pkg/gameservers implements two disjoint features:

• controller for GS
• SDK server and local SDK server

I think we need to keep SDK binary small and free of dependencies it does not need (to reduce attack surface and memory footprint). Right now we're relying on linker to exclude controller-related code from sdk-server binary. While the linker is presently doing a good job, it's very easy to accidentally add an init() function which will bring unwanted dependency on controller code to SDK binary.

I suggest we move sdk.go and localsdk.go and related files to pkg/sdkserver before they become entangled.

[markmandel]

Hey @enocom my resident go champion 😄 what are your thoughts?

Is this a code review issue, or something you think we should take proactive action on?

I don't think I have strong opinions either way to be honest - but the original organisational model idea was to match packages to the K8s resources that they were responsible for -- so in this case the sdkserver modified the GameServer resource, so it goes in the gameservers package.

[enocom]

Splitting out the SDK server and local SDK server seems like a good idea. Their responsibilities also seem distinct from the controller.

Are there other examples in the code where a Kubernetes controller gets its own package?

[markmandel]

So in K8s, all the controllers can be found in subpackages under https://github.com/kubernetes/kubernetes/tree/master/pkg/controller - so organising by type of object. Which has it's own pros and cons!

[enocom]

At this point, it seems more a matter of style. If there consumers of just the controller or just the SDK server, it might be easier to see the benefits of this refactor.