<p>If I create 3 nodes in a cluster, how do I distribute the docker containers evenly across the containers? For example, if I create a cluster of 3 nodes with 8 cpus on each node, I've determined through performance profiling that I get the best performance when I run one container per cpu.</p>

<pre><code>gcloud container clusters create mycluster --num-nodes 3 --machine-type n1-standard-8

kubectl run myapp --image=gcr.io/myproject/myapp -r 24
</code></pre>

<p>When I ran <code>kubectl</code> above, it put 11 containers on the first node, 10 on the second, and 3 on the third. How to I make it so that it is 8 each?</p>

<p>Both your and jpapejr's solutions seem like they'd work, but using a <code>nodeSelector</code> to force scheduling to a single node has the downside of requiring multiple RCs for a single application and making that application less resilient to a node failure. The idea of a custom scheduler is nice but has the downside of the amount of work to write and maintain that code.</p>

<p>I <em>think</em> another possible solution would be to set runtime constraints in your pod spec that might get you near to what you want. Based on <a href="https://github.com/kubernetes/kubernetes/tree/master/examples/runtime-constraints" rel="nofollow">this newly merged doc with examples of runtime contraints</a>, I think you could set <code>resources.requests.cpu</code> in the pod spec part of the RC and get close to a CPU-per-pod:</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
    - name: myapp
      image: myregistry/myapp:v1
      resources:
        requests:
          cpu: "1000m"
</code></pre>

<p>That docs has other good examples of how <code>requests</code> and <code>limits</code> differ and interact. There may be a combination that gives you what you want and also keeps your application at proper capacity when an individual node fails.</p>
