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. Initial resource request for CPU and memory Upper limit until we want our application to grow at max 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. 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 Example 2-3. Resource limits Solution  |  19