
Scaling Dedicated Game Servers with Kubernetes: Part 2 – Managing CPU and Memory - markmandel
http://www.compoundtheory.com/scaling-dedicated-game-servers-with-kubernetes-part-2-managing-cpu-and-memory/
======
NocV
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...](https://cloudplatform.googleblog.com/2016/09/bringing-Pokemon-GO-
to-life-on-Google-Cloud.html)

~~~
markmandel
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.

~~~
NocV
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.

~~~
markmandel
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.

------
buzer
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

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

