Currently thundernetes uses a sidecar to

• handle GSDK heartbeats
• update the GameServer/GameServerDetail CRs with the updated status of the game server process
• create a Watch towards the K8s API server to get a notification when the game server has been allocated

The sidecar is dynamically created by thundernetes when a new game server Pod is created

We will change this implementation to use a DaemonSet instead. The DaemonSet process will listen to heartbeats coming from the same Node (game server Pods scheduled on the same Node as the corresponding DaemonSet Pod) and will create a Watch only for the GameServer CRs which have Pods on that Node. The benefits to using a DaemonSet over a sidecar are:

• more lightweight approach on the GameServer Pod, since we're going to have one less container (faster to start, smaller consumption of resources)
• less pressure on the K8s API server since we will have less Watches (just one for each Node)
• ability to support hostNetwork by the GameServer Pods (Consider Host Networking mode for pods #22)
• easier way to grab prometheus metrics for connected players (allocator draft #28)