<h3>Context</h3>
<p>I am running a job-processing task (specifically, <a href="https://github.com/resque/resque" rel="nofollow noreferrer">Resque</a>) in a kubernetes setup. This task sets up one or more workers to takes job messages off a queue and processes them. A typical invocation is to set your desired worker count, e.g. <code>COUNT=8 QUEUE=* resque:work</code>.</p>
<p>Of course, in Kubernetes, I am going to add autoscaling to the Deployment running this task.</p>
<p>There's a prevailing recommendation to run 1 process per pod (see below). My concern is that doing so can be wasteful when the process I wish to run has a built-in multi-process management system to run identical processes. I am trying to understand the theory &amp; docs to inform decisions and experiments.</p>
<p>My motivation question is: is there any reason to continue setting worker count, or does it make more sense to use only one worker process per pod? I.e. is there significant overhead in each pod instance compared to letting Resque spawn multiple processes?</p>
<h3>Question</h3>
<p>The objective question is: where should I expect / look for overhead in running 1 process per pod vs letting 1 pod's main process spawn multiple children?</p>
<p>E.g. IIUC each pod is running its own version of the OS and other utils installed in the container. So that at least is some memory overhead vs running a single container, single OS, mutli-Resque-worker setup; is that correct? What else should I be looking at, prior to simply benchmarking a bunch of guesses, to model resource consumption for this setup?</p>
<h3>More Context</h3>
<p>I understand that small process count allows for more granular scaling. I don't consider scaling at a finer resolution than, say, 4 processes at a time to be much benefit, so I'd start there if pod overhead should be considered. Am I overthinking it, and should I forget about pod overhead and just use a worker count of 1 per pod?</p>
<p>This question is informed off of many &quot;one process per pod&quot; references out there. Many listed in <a href="https://stackoverflow.com/questions/60758848/does-it-make-sense-to-run-multiple-similar-processes-in-a-container">this similar question</a> and a <a href="https://devops.stackexchange.com/questions/447/why-it-is-recommended-to-run-only-one-process-in-a-container">stack exchange question linked therein</a>.</p>
<ul>
<li>The linked question was concerned with scaling processes inside a pod to optimize node compute usage, which I get is well managed by k8s already</li>
<li>The nested links are more about limiting to one <em>concern</em> per pod, which is the case in my question.</li>
</ul>
<p>My question is about overhead of running 4 identical worker processes in 4 pods vs in 1 pod.</p>

<p>Either way is fine and I wouldn't expect it to make a huge difference, except maybe at large scale.</p>
<p>There is nothing architecturally wrong with running multiple worker tasks inside a single container, particularly within a framework that's specifically designed to do it.  As you note it's usually considered good form to run one concern per container, and there are various issues with running multiple processes (recovering from failed processes, collecting logs); but if you have a system that's specifically designed to launch and manage subprocesses, running it in a container is fine.</p>
<p>The questions I'd start asking here are around how many Resque workers you're planning to run at the same time.  If it's &quot;thousands&quot;, then you can start hitting limits around the number of pods per node and pressure on the Kubernetes scheduler.  In that case, using multiple workers per container to cut down the number of pods can make some sense.  If it's &quot;dozens&quot; then limiting it to just one could make it a little easier to visualize and manage.</p>
<p>Starting up a new container can be somewhat expensive (I'm used to seeing 30-60s startup times, but depending heavily on the image) but having a running container isn't especially so.  It looks like Resque has a manager process on top of some number of workers so you'll have those extra Rubies, but that's probably not significant memory or storage.</p>
