Scaling Dedicated Game Servers with Kubernetes: Part 2 – Managing CPU and Memory | Hacker News Reader

Scaling Dedicated Game Servers with Kubernetes: Part 2 – Managing CPU and Memory

compoundtheory.com

57 pointsmarkmandel6 comments

From the first part of the series.

  While I am aware of more than a few companies that are containerising their game servers and running them in production, I am not aware of any that are doing so on Kubernetes.

I believe Pokemon GO is using Kubernetes, which is one of the biggest multiplayer mobile games in the world at the moment.

Link: https://cloudplatform.googleblog.com/2016/09/bringing-Pokemo...

In response to this - afaik, there is no evidence that Pokemon Go is running stateful game simulation servers for their game, especially those that would power something like an FPS or MMO (They may be, but I've not seen any public evidence of it), which is what I'm referring to in this article. Sounds like I should have been clearer on this point, as you aren't the first to point this out.

Yeah, i never implied the Pokemon GO server was stateful (and it definitely isn't) in the way that other MMOs/FPSs that require persistent connections are. However, you can't say that it isn't a "game server".

I looked through comments to see if anyone had pointed it out and didn't see anything. Figured maybe you'd be interested to know that Kubernetes was used for something so massive. My bad.

No worries - and thanks for pointing it out (I meant you weren't the first person to say this to me). It's worth the clarification.

It's an interesting differentiation in vocabulary between the games industry and what would be the wider technical community, in my experience - a "game server" is a simulation server when talking about it in the games industry. I should have made a note of that in the previous article.

Regarding the first article, strictly speaking it isn't necessary to use hostNetwork, but to actually do it in standard public cloud environment isn't really possible.

Normally it's good idea to avoid hostNetwork as it creates quite a bit of limitations. For example, you cannot use network security policies and you cannot use deployments to assign more than 1 pod per node. To allow same application to run multiple instances on same node, you would need to create multiple deployments with different ports.

To avoid hostNetwork, essentially what is required is that you need publicly routable addresses for each pod (1:1 NAT is also possible, but it's quite a bit more complicated, e.g. you probably need create custom ingress controller which creates the 1:1 NAT mappings) which is also the reason why this doesn't really work in public cloud environments. If you can accomplish that though, you get to use all of Kubernetes' standard features on your pods.

tl;dr NAT sucks

FYI to the OP, the website shows a blank page when JavaScript is disabled.

Reply on news.ycombinator.com