or to kill are subject to gaming by users. Any change could affect many Pods, and could prevent the platform from delivering predictable service-level agreements. Kubernetes is a self-service platform that enables developers to run applications as they see suitable on the designated isolated environments. However, working in a shared multitenanted platform also requires the presence of specific boundaries and control units to prevent some users from consuming all the resources of the platform. One such tool is ResourceQuota, which provides constraints for limiting the aggrega‐ ted resource consumption in a namespace. With ResourceQuotas, the cluster admin‐ istrators can limit the total sum of computing resources (CPU, memory) and storage consumed. It can also limit the total number of objects (such as ConfigMaps, Secrets, Pods, or Services) created in a namespace. Another useful tool in this area is LimitRange, which allows setting resource usage limits for each type of resource. In addition to specifying the minimum and maxi‐ mum permitted amounts for different resource types and the default values for these resources, it also allows you to control the ratio between the  requests  and  limits , also known as the  overcommit level . Table 2-1 gives an example how the possible val‐ ues for  requests  and  limits  can be chosen. LimitRanges are useful for controlling the container resource profiles so that there are no containers that require more resources than a cluster node can provide. It can also prevent cluster users from creating containers that consume a large number of resources, making the nodes not allocatable for other containers. Considering that the  requests  (and not  limits ) are the primary container characteristic the scheduler uses for placing, LimitRequestRatio allows you to control how much difference there is between the  requests  and  limits  of containers. Having a big combined gap between  requests  and  limits  increases the chances for overcommitting on the node and may degrade application performance when many containers simultaneously require more resources than originally requested. Considering that containers may have different resource profiles in different environ‐ ments, and a varied number of instances, it is evident that capacity planning for a multipurpose environment is not straightforward. For example, for best hardware 22  |  Chapter 2: Predictable Demands Capacity Planning Table 2-1. Limit and request ranges Type Resource Min Max Default limit Default request Lim/req ratio Container CPU 500m 2 500m 250m 4 Container Memory 250Mi 2Gi 500Mi 250Mi 4 Project Resources