Answers: <p>It seems like you found your answer but let me add a little color since we went through the same thing.  </p>
  
  <p>Your yaml for the pods can have both a request and limit for both CPU and memory.  Since you are discussing CPU here I'll stick with that.  What you can do in order to utilize your resources efficiently is set your resource request to the minimum requirement to get scheduled. Say 1.8.  But also set the limit to a higher limit, say 2 or more.  What this will do is make your pod be schedulable on the machine and if CPU is not completely consumed, your pod will utilize the available CPU up to 2 or the limit you set.  This is the way kubernetes can make good use of the resources by "sharing" CPU to the application that needs it. </p>
  
  <p>See here for requests and limits:
  <a href="https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-27T07:24:29.067Z
Answers: What would happen if say, I had a node with 4 CPU (meaning 3.72 available) and I scheduled a pod with request 1.8 and limit 2. The pod would consume 2 CPU since nothing else wants it, but then if i wanted to schedule another pod with request 1.8 limit 2 it would not have enough CPU? or would it reduce the CPU of the pod that is already there?
Answers: Inbar Rose
Answers: CC BY-SA 4.0
Answers: 2018-06-28T21:16:02.543Z
Answers: Kubernetes will schedule the pod based on an algorithm of what's available.  So if it is consuming the 2 (or more) it won't be scheduled. But if you have burst loads then it will schedule when the burst is down.  You request basically your minimum average.  I would say if your load isn't burstable or your worried about not having the .2 cores per process I would upgrade to the 6 to leave room for pods going up and down.  Then your overhead (wasted .28 cpu's) is only that one.  Unless you are worried about HA, rolling updates etc then one vm isn't going to be good.  Hope that helps
Answers: Jeff Garrett
Answers: CC BY-SA 4.0
Answers: 2018-06-26T16:36:21.900Z
Answers: 2018-06-26T16:36:21.900Z
Answers: Jeff Garrett
Body: <p>I have a Kubernetes Cluster on GCE (Google Cloud Engine) (Also called GKE - Google Kubernetes Engine). </p>
  
  <p>The Cluster is configured to have <strong>4cpu</strong> per node. The pods I am using request <strong>2cpu</strong>. I expect to be able to have <strong>2 pods per node</strong>. But instead each time I launch a new pod, it also provisions a new node (am <em>only</em> getting <strong>1 pod per node</strong>).</p>
  
  <p>What is happening, How can I more efficiently use my resources? (I don't want to pay for nodes that are under-utilized)</p>
  
  <p>Node:</p>
  
  <blockquote>
    <p>Machine type<br>
    n1-highcpu-4 (4 vCPUs, 3.6 GB memory)</p>
  </blockquote>
  
  <p>Pod (Yaml):</p>
  
  <pre><code>resources:
    limits:
      cpu: "2"
      memory: 1000Mi
    requests:
      cpu: "2"
      memory: 1000Mi
  </code></pre>
  
  <p><strong>EDIT:</strong></p>
  
  <p>As mentioned below in the comments; it seems there are some 'default' pods that run on the node which utilize some small amount of CPU. For me there were two service pods taking up 100mcpu each. Additionally it seems there is a small overhead regardless of those small pods when viewing my node resources I see:</p>
  
  <pre><code>Resource type   Capacity   Allocatable   
  CPU             4 CPU      3.92 CPU
  </code></pre>
  
  <p>This means that each node in my cluster will only have 3.72 CPU that I can distribute to my pods. (3.92 allocatable, - 100m CPU per service pod (x2) = 3.72)</p>
  
  <p><strong>Knowing this, I can understand why my desired deployment will not work.</strong> </p>
  
  <p>However, now this raises new questions; How can I most efficiently allocate pods that need 2cpu. Since GCE only lets me provision nodes with even numbers of cpu (2,4,6,etc) I will always have almost 2 wasted CPU. Is there a better solution?</p>
  
  <p><strong>EDIT2:</strong></p>
  
  <p>Settings my pods to use 1.8 CPU allowed me to deploy 2 pods per node. (and for now is good enough)
  It would be desirable to be able to anticipate the overhead on nodes. For example, in my use-case above, allocating 4CPU per node, I should be able to know ahead of time that after the service pods and allocatable CPU are considered I will only be able to use 3.72 for my own pods. But if I now want to provision a new Node with 8CPU I will need to check these numbers all over again. </p>
  
Comments: CC BY-SA 4.0
Comments: 2018-06-13T14:20:12.263Z
Comments: IIRC you have other pods runnings on each node, at least one for K8S itself, so obvisouly you can't use 4 cpu with your own 2 pods as there's already 0.1 or 0.2 used by other pods than yours and the scheduler knowing that raise a new node to host the new pod of 2cpu, try with 1.8 to see if it change the behavior.
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-13T14:38:50.013Z
Comments: nodes can only be defined on GCE using even numbers (2,4,6,etc) meaning that if i want to have a pod that uses 2cpu I will always be under-utilizing my node by almost 2 cpus? this seems like a serious waste of resource. Surely there must be a solution.
Comments: Inbar Rose
Comments: CC BY-SA 4.0
Comments: 2018-06-13T14:45:45.643Z
Comments: A 4cpu node can handle at least three 1 cpu pod, a pod needing absolutely 2 cpu sounds like someting which has nothing to do in a containers where we usually play with less than 1 cpu reservation per pod.
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-13T14:52:39.140Z
Comments: Try with cpu: "1.7" in your requests blocks and see if it really is a problem for your pods...
Comments: Tensibai
Comments: CC BY-SA 4.0
Comments: 2018-06-13T14:52:43.343Z
Comments: My use-case requires strong CPU. I can probably allocate 1.8 and it will be fine. But a 2cpu pod should not be such a strange use-case, nor a hard to accommodate deployment. And it's frustrating that there is so much overhead/constraints.
Comments: Inbar Rose
Comments: CC BY-SA 4.0
Comments: 2018-06-13T14:55:43.583Z
Comments: just FYI - 1.8 works for me and works as a solution for now. But it would be desirable to have a way to anticipate the overheads so I can more efficiently provision nodes.
Comments: Inbar Rose
Tags: <kubernetes><google-compute-engine>
Title: kubernetes cluster node with 4cpu can't hold two pods with 2cpu
UserDisplayName: Inbar Rose
ThreadText: # kubernetes cluster node with 4cpu can't hold two pods with 2cpu
  
  (Asked by: username_0 on 2018-06-13)
  
  I have a Kubernetes Cluster on GCE (Google Cloud Engine) (Also called GKE - Google Kubernetes Engine).
  
  The Cluster is configured to have **4cpu** per node. The pods I am using request **2cpu**. I expect to be able to have **2 pods per node**. But instead each time I launch a new pod, it also provisions a new node (am *only* getting **1 pod per node**).
  
  What is happening, How can I more efficiently use my resources? (I don't want to pay for nodes that are under-utilized)
  
  Node:
  
  > Machine type  
  > n1-highcpu-4 (4 vCPUs, 3.6 GB memory)
  
  Pod (Yaml):
  
  ```
  resources:
    limits:
      cpu: "2"
      memory: 1000Mi
    requests:
      cpu: "2"
      memory: 1000Mi
  
  ```
  
  **EDIT:**
  
  As mentioned below in the comments; it seems there are some 'default' pods that run on the node which utilize some small amount of CPU. For me there were two service pods taking up 100mcpu each. Additionally it seems there is a small overhead regardless of those small pods when viewing my node resources I see:
  
  ```
  Resource type   Capacity   Allocatable   
  CPU             4 CPU      3.92 CPU
  
  ```
  
  This means that each node in my cluster will only have 3.72 CPU that I can distribute to my pods. (3.92 allocatable, - 100m CPU per service pod (x2) = 3.72)
  
  **Knowing this, I can understand why my desired deployment will not work.**
  
  However, now this raises new questions; How can I most efficiently allocate pods that need 2cpu. Since GCE only lets me provision nodes with even numbers of cpu (2,4,6,etc) I will always have almost 2 wasted CPU. Is there a better solution?
  
  **EDIT2:**
  
  Settings my pods to use 1.8 CPU allowed me to deploy 2 pods per node. (and for now is good enough)
  It would be desirable to be able to anticipate the overhead on nodes. For example, in my use-case above, allocating 4CPU per node, I should be able to know ahead of time that after the service pods and allocatable CPU are considered I will only be able to use 3.72 for my own pods. But if I now want to provision a new Node with 8CPU I will need to check these numbers all over again.
  
  **Tags:** kubernetes, google-compute-engine
  
  > **Comments:**
  > **username_1**: IIRC you have other pods runnings on each node, at least one for K8S itself, so obvisouly you can't use 4 cpu with your own 2 pods as there's already 0.1 or 0.2 used by other pods than yours and the scheduler knowing that raise a new node to host the new pod of 2cpu, try with 1.8 to see if it change the behavior.  
  > **username_0**: nodes can only be defined on GCE using even numbers (2,4,6,etc) meaning that if i want to have a pod that uses 2cpu I will always be under-utilizing my node by almost 2 cpus? this seems like a serious waste of resource. Surely there must be a solution.  
  > **username_1**: A 4cpu node can handle at least three 1 cpu pod, a pod needing absolutely 2 cpu sounds like someting which has nothing to do in a containers where we usually play with less than 1 cpu reservation per pod.  
  > **username_1**: Try with cpu: "1.7" in your requests blocks and see if it really is a problem for your pods...  
  > **username_0**: My use-case requires strong CPU. I can probably allocate 1.8 and it will be fine. But a 2cpu pod should not be such a strange use-case, nor a hard to accommodate deployment. And it's frustrating that there is so much overhead/constraints.  
  > **username_0**: just FYI - 1.8 works for me and works as a solution for now. But it would be desirable to have a way to anticipate the overheads so I can more efficiently provision nodes.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-06-26. Score: 1
  
  It seems like you found your answer but let me add a little color since we went through the same thing.
  
  Your yaml for the pods can have both a request and limit for both CPU and memory. Since you are discussing CPU here I'll stick with that. What you can do in order to utilize your resources efficiently is set your resource request to the minimum requirement to get scheduled. Say 1.8. But also set the limit to a higher limit, say 2 or more. What this will do is make your pod be schedulable on the machine and if CPU is not completely consumed, your pod will utilize the available CPU up to 2 or the limit you set. This is the way kubernetes can make good use of the resources by "sharing" CPU to the application that needs it.
  
  See here for requests and limits:
  <https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/>
  
  > **Comments:**
  > **username_0**: What would happen if say, I had a node with 4 CPU (meaning 3.72 available) and I scheduled a pod with request 1.8 and limit 2. The pod would consume 2 CPU since nothing else wants it, but then if i wanted to schedule another pod with request 1.8 limit 2 it would not have enough CPU? or would it reduce the CPU of the pod that is already there?  
  > **username_2**: Kubernetes will schedule the pod based on an algorithm of what's available.  So if it is consuming the 2 (or more) it won't be scheduled. But if you have burst loads then it will schedule when the burst is down.  You request basically your minimum average.  I would say if your load isn't burstable or your worried about not having the .2 cores per process I would upgrade to the 6 to leave room for pods going up and down.  Then your overhead (wasted .28 cpu's) is only that one.  Unless you are worried about HA, rolling updates etc then one vm isn't going to be good.  Hope that helps  
  
  ---
  
  