content_image/835722.jpg content_image/835723.jpg
The requests  amount (but not limits ) is used by the scheduler when placing Pods to nodes. For a given Pod, the scheduler considers only nodes that still have enough capacity to accommodate the Pod and all of its containers by summing up the reques‐ ted resource amounts. In that sense, the requests  field of each container affects where a Pod can be scheduled or not. Example 2-3 shows how such limits are speci‐ fied for a Pod. 

apiVersion : v1 kind : Pod metadata : name : random-generator spec : containers : - image : k8spatterns/random-generator:1.0 name : random-generator resources : requests : cpu : 100m memory : 100Mi limits : cpu : 200m memory : 200Mi 

Initial resource request for CPU and memory 

<img src='content_image/835722.jpg'>

Upper limit until we want our application to grow at max 

<img src='content_image/835723.jpg'>

Depending on whether you specify the requests , the limits , or both, the platform offers a different kind of Quality of Service (QoS). 

Best-Effort 

Pod that does not have any requests and limits set for its containers. Such a Pod is considered as the lowest priority and is killed first when the node where the Pod is placed runs out of incompressible resources. 

Burstable 

Pod that has requests  and limits  defined, but they are not equal (and limits  is larger than requests  as expected). Such a Pod has minimal resource guarantees, but is also willing to consume more resources up to its limit  when available. When the node is under incompressible resource pressure, these Pods are likely to be killed if no Best-Effort Pods remain. 

