Container CPU and Memory requests and limits configuration guarantees a minimum amount of resources to a container and sets a maximum consumable amount.
Resource Configuration Values
Memory is measured in bytes and expressed as an integer or using a fixed point integer. For example; memory: 1 is 1 byte, memory: 1Mi is 1 mebibyte / megabyte, memory: 1Gi is 1 gibibyte / gigabyte. Memory is not a compressible resource, and there is no throttling. Kubernetes evicts a pod from a node If a node cannot provide sufficient memory,
CPU is measure in millicpus, which is 1/1000th of a CPU core and expressed with integers. For example; cpu: "1" is 1 CPU, cpu: 2000m is 2 CPUs, cpu: "0.75" is 0.75 of a cpu and equivalent to cpu: 750m. CPU is a compressible resource and can be throttled by Kubernetes during contention. CPU contention does not cause pod eviction; instead, the app is slowed down.
Requests
Requests represent the number of resources guaranteed to a container. This setting should be the same as or slightly above the minimum amount required for the container to function. The requests value for a pod is the sum of all requests for each container configured within that pod. A pod cannot start on a node unless the node has enough available resources for pods request value.
Configuring a low value for requests improves the chances that a container gets scheduled.
Limits
A limit sets the maximum quantity of a Memory or CPU that a container can consume.
Per container limits are configured within the relevant manifest file. There is no upper limit to the amount of memory or CPU that a container can consume if limits are not specified.
Cluster administrators can configure default limits on a namespace using a LimitRange. Containers inherit namespace default limits if there are none configured at the container level.
If a container has a CPU or Memory limit set, but no requests value, the request value will equal the limit.
Memory Examples
Example multi-container pod:
| |
A node must be able to provide at least 512Mi of RAM, or the namespace must have 512Mi available for the pod to start.
Insufficent Memory Available:
| |
| |
There is no attempt from the scheduler to start a single container within the pod because there is no node with sufficient memory for the entire pod.
Memory limit set, no request
| |
| |
Requests value is 512Mi because a limit is set and no request value was configured.
CPU Examples
A pod cannot be scheduled on a node if the CPU requests value is higher then the nodes total physical cores. Just like with memory, a pods CPU requests value is the sum of all containers within the pod.
The nodes in my lab have 2 CPU cores each and the pod configuration below requests a 1 CPU in total.
Example multi-container pod:
| |
This pod has no issues starting in the lab because the nodes have sufficient physical CPU.
Insufficent CPU Available:
| |
| |
This pod could not start because the combined CPU requests exceeded the physical CPU cores.
Memory limit set, no request
| |
| |
The CPU requests match the limits value has no requests value is configured in the manifest.
Summary
Configuring limits and requests is a Kubernetes management best practice which improves resource allocation and scheduling. It is a good idea to configure monitoring to detect where limits and requests are not configured.