<p>I understand the concept of setting a <code>request</code> or a <code>limit</code> on a Kubernetes pod for both <code>CPU</code> and/or <code>memory</code> resources but I'm trying to understand what happens if you don't set either <code>request</code> or <code>limit</code> for say a CPU?</p>
<p>We have configured an NGINX pod but it doesn't have either a <code>request</code> or <code>limit</code> set for its <code>CPU</code>. I'm assuming it will have at a minimum <code>1 millicore</code> and will give as much millicores to that pod as it needs and is available on the node. If the node has exhausted all available cores, then does it just stay stuck at 1 millicore?</p>

n00b
<p><strong>What happens if you don't set either request or limit for say a CPU?</strong></p>
<blockquote>
<p>When you don’t specify a request for CPU, you’re saying you don’t
care how much CPU time the process running in your container is
allotted.</p>
</blockquote>
<blockquote>
<p>In the worst case, it may not get any CPU time at all (this happens
when a heavy demand by other processes exists on the CPU). Although
this may be fine for low-priority batch jobs, which aren’t
time-critical, it obviously isn’t appropriate for containers handling
user requests.</p>
</blockquote>
<blockquote>
<p>you’re also requesting <code>1 millicore</code> of memory for the container. By
doing that, you’re saying that you expect the processes running
inside the container to use at most <code>N mebibytes</code> of RAM. They
might use less, but you’re not expecting them to use more than that
in normal circumstances.</p>
</blockquote>
<p><strong>Understanding how resource requests affect scheduling</strong></p>
<blockquote>
<p>By specifying resource requests, you’re specifying the minimum amount of resources your pod needs. This information is what the Scheduler uses when scheduling the pod to a node.</p>
</blockquote>
<blockquote>
<p>Each node has a certain amount of CPU and memory it can allocate to pods. When scheduling a pod, the Scheduler will only consider nodes with enough unallocated resources to meet the pod’s resource requirements.</p>
</blockquote>
<blockquote>
<p>If the amount of unallocated CPU or memory is less than what the pod requests, Kubernetes will not schedule the pod to that node, because the node can’t provide the minimum amount required by the pod.</p>
</blockquote>
<p><strong>Understanding what will happened if Exceeding the limits</strong></p>
<p><strong>With CPU</strong></p>
<blockquote>
<p>CPU is a compressible resource, and it’s only natural for a process to want to consume all of the CPU time when not waiting for an I/O operation.</p>
</blockquote>
<blockquote>
<p>a process’ CPU usage is throttled, so when a CPU limit is set for a container, the process isn’t given more CPU time than the configured limit.</p>
</blockquote>
<p><strong>With Memory</strong></p>
<blockquote>
<p>With memory, it’s different. When a process tries to allocate memory over its limit, the process is killed (it’s said the container is <code>OOMKilled</code>, where <code>OOM</code> stands for Out Of Memory).
If the pod’s restart policy is set to Always or <code>OnFailure</code>, the process is restarted immediately, so you may not even notice it getting killed. But if it keeps going over the memory limit and getting killed, Kubernetes will begin restarting it with increasing delays between restarts. You’ll see a <code>CrashLoopBackOff</code> status in that case.</p>
</blockquote>
<pre><code>kubectl get po
NAME        READY     STATUS             RESTARTS   AGE
memoryhog    0/1   CrashLoopBackOff         3       1m
</code></pre>
<p><strong>Note:</strong> The <code>CrashLoopBackOff</code> status doesn’t mean the Kubelet has given up. It means that after each crash, the Kubelet is increasing the time period before restarting the container.</p>
<p><strong>Understand To examine why the container crashed</strong></p>
<pre><code>kubectl describe pod
Name:
...
Containers:
main: ...
    State: Terminated
      Reason: OOMKilled
...
</code></pre>
<blockquote>
<p>Pay attention to the Reason attribute <code>OOMKilled</code>. The current container was killed because it was out of memory (OOM).</p>
</blockquote>
