<ul>
<li><p>Can Kubernetes pods share significant amount of memory?</p>
</li>
<li><p>Does copy-on-write style forking exist for pods?</p>
</li>
</ul>
<p>The purpose is to make pods spawn faster and use less memory.</p>
<p>Our scenario is that we have a dedicated game server to host in kubernetes. The problem is that one instance of the dedicated game server would take up a few GB of memory upfront (e.g. 3 GBs).</p>
<p>Also, we have a few such docker images of game servers, each for game A, game B... Let's call a pod that's running game A's image for game A <code>pod A</code>.</p>
<p>Let's say we now have 3 x <code>pod A</code>, 5 x <code>pod B</code>. Now players rushing into game B, so I need let's say another 4 * <code>pod B</code> urgently.</p>
<p>I can surely spawn 4 more <code>pod B</code>. Kubernetes supports this perfectly. However there are 2 problems:</p>
<ul>
<li>The booting of my game server is very slow (30s - 1min). Players don't want to wait.</li>
<li>More importantly for us, the cost of having this many pods that take up so much memory is very high. Because pods do not share memory as far as I know. Where as if it were plain old EC2 machine or bare metal, processes can share memory because they can fork and then copy-on-write.</li>
</ul>
<p>Copy-on-write style forking and memory sharing seems to solve both problems.</p>

<p>A different way to resolve the issue would be if some of the initialisation can be baked into the image.</p>
<p>As part of the docker image build, start up the game server and do as much of the 30s - 1min initialisation as possible, then dump that part of the memory into a file in the image. On game server boot-up, use <code>mmap</code> (with <code>MAP_PRIVATE</code> and possibly even <code>MAP_FIXED</code>) to map the pre-calculated file into memory.</p>
<p>That would solve the problem with the game server boot-up time, and probably also with the memory use; everything in the stack <em>should</em> be doing copy-on-write all the way from the image through to the pod (although you'd have to confirm whether it actually does).</p>
<p>It would also have the benefit that it's plain k8s with no special tricks; no requirements for special permissions or node selection or anything, nothing to break or require reimplementation on upgrades or otherwise get in the way. You will be able to run it on any k8s cluster, whether your own or any of the cloud offerings, as well as in your CI/CD pipeline and dev machine.</p>
