<p>How are Kubernetes Ressource Requests handled in practice, if the "owner" does not use these resources, but another pod would require them? Will they temporarily be granted to the other ressource or do they lead to idle status? </p>

<p>Example: Given two Pods/Deployments (on the same node): </p>

<ul>
<li>Pod A (Requests 40% CPU)  </li>
<li>Pod B (Requests 60% CPU, Limit 80% CPU)</li>
</ul>

<p>Pod A crashes internally, so will never use any ressources (actual usage 0%). 
Questions: </p>

<ol>
<li>Can Pod B Use the 80%, or will it be limited to 60% (to reseve the guaranteed 40% to Pod A, even though Pod A will never use these 40%, effectively leading to 40% Idle Status?)</li>
<li>Could Pod B even getting more than the 80% (on an idle System) or is the 80% absolutely hard enforced? </li>
</ol>

<p>I have not found any docs explaining this in details (they only talk about schedlung based on resources), any links would be very much appreciated...Background/Motivation: I have an extremely slow node app on a pod and I suspect this is realated to Resource Request/Limits... Thanks very much!</p>

Markus
<p>Resource <em>requests</em> only affect pods placement on nodes.  In your example, the node has 100% CPU requests worth of pods on it, so (assuming the node has 1 CPU) nothing else can get scheduled there.</p>

<p>CPU <em>limits</em> throttle the process running.  If B is in a busy loop of some sort, it will never get more than 80% CPU.  It could use all of that 80% CPU, even if it only requested 60% and other scheduled pods have requested the other 40%; only the limit matters here.  It could get less, if A is also trying to use 40% or 100%; the kernel will allocate things according to its own policy.</p>

<p>(Memory works similarly, except that the kernel can't time-slice memory if the system is overcommitted, so it will kill off an arbitrary process, usually the one with the highest memory usage.)</p>
