<p>Coming from numerous years of running node/rails apps on bare metal; i was used to be able to run as many apps as i wanted on a single machine (let's say, a 2Go at digital ocean could easily handle 10 apps without worrying, based on correct optimizations or fairly low amount of traffic)</p>

<p>Thing is, using kubernetes, the game sounds quite different.  I've setup a "getting started" cluster with 2 standard vm (3.75Go).</p>

<p>Assigned a limit on a deployment with the following :</p>

<pre><code>        resources:
          requests:
            cpu: "64m"
            memory: "128Mi"
          limits:
            cpu: "128m"
            memory: "256Mi"
</code></pre>

<p>Then witnessing the following :</p>

<pre><code>Namespace       Name            CPU Requests    CPU Limits  Memory Requests Memory Limits
---------       ----            ------------    ----------  --------------- -------------
default         api             64m (6%)        128m (12%)  128Mi (3%)      256Mi (6%)
</code></pre>

<p>What does this 6% refers to ?</p>

<p>Tried to lower the CPU limit, to like, 20Mi… the app does to start (obviously, not enough resources). The docs says it is percentage of CPU. So, 20% of 3.75Go machine ? Then where this 6% comes from ? </p>

<p>Then increased the size of the node-pool to the n1-standard-2, the same pod  effectively span 3% of node. That sounds logical, but what does it actually refers to ?</p>

<p>Still wonder what is the metrics to be taken in account for this part.</p>

<p>The app seems to need a large amount of memory on startup, but then it use only a minimal fraction of this 6%. I then feel like I misunderstanding something, or misusing it all</p>

<p>Thanks for any experienced tips/advices to have a better understanding
Best</p>

<p>According to the <a href="https://kubernetes.io/docs/user-guide/compute-resources/" rel="noreferrer">docs</a>, CPU requests (and limits) are always fractions of available CPU cores on the node that the pod is scheduled on (with a <code>resources.requests.cpu</code> of <code>"1"</code> meaning reserving one CPU core exclusively for one pod). Fractions are allowed, so a CPU request of <code>"0.5"</code> will reserve half a CPU for one pod.</p>

<p>For convenience, Kubernetes allows you to specify CPU resource requests/limits in <em>millicores</em>:</p>

<blockquote>
  <p>The expression <code>0.1</code> is equivalent to the expression <code>100m</code>, which can be read as “one hundred millicpu” (some may say “one hundred millicores”, and this is understood to mean the same thing when talking about Kubernetes). A request with a decimal point, like <code>0.1</code> is converted to <code>100m</code> by the API, and precision finer than <code>1m</code> is not allowed.</p>
</blockquote>

<p>As already mentioned in the other answer, resource requests are <em>guaranteed</em>. This means that Kubernetes will schedule pods in a way that the sum of all <em>requests</em> will not exceed the amount of resources actually available on a node.</p>

<p>So, by requesting <code>64m</code> of CPU time in your deployment, you are requesting actually 64/1000 = 0,064 = 6,4% of one of the node's CPU cores time. So that's where your 6% come from. When upgrading to a VM with more CPU cores, the amount of available CPU resources increases, so on a machine with two available CPU cores, a request for 6,4% of <em>one</em> CPU's time will allocate 3,2% of the CPU time of <em>two</em> CPUs.</p>
