CPU requests and limits¶

Units¶

The CPU requests and limits can be specified in some formats:

Using a number, with or without decimals
Using milicores / milicpu (a cpu capacity / 1000)

For values less that 1 CPU, it is recommended to use the milicpu format and not the decimal format

resources:
    requests:
    cpu: 2 # 2 CPU

resources:
    requests:
    cpu: 0.5 # Half CPU

resources:
    requests:
    cpu: "200m" # 200 milicores = 0.2

If we define a cpu limit but not a CPU request, kubernetes gives both the same value.

CPU request¶

Giving a CPU request to a kubernetes container has some implications:

Scheduling:

Kube scheduler will assign that pod to a node that has that CPU resources as available. If no node has that resources the pod will be in Pending state until they new resources are available.

Guarantee:

Once the container is up in the node, that CPU resources will be guaranteed.

Weight in CPU contention:

The requested CPU will be used during CPU contention situations in the node. Containers with higher CPU requests will have higher priority accesing the node CPU.

Este maximo de cpu que puede lograr vendra dado por la capacidad del nodo o, si el container tiene cpu limit, por dicho limite.

HPA

That value will be used in the CPU horizontal pod autoescaler

CPU limit¶

The CPU limit in kubernetes is controlled by the linux kernel and the Completely Fair Scheduler (CFS).

It can be defined as the maximum CPU time a container can use every in a CPU cycle interval

The CPU limit is translated to the CFS as the cpu_quota_us setting, and the cycle interval as the cpu_period_us

The default cpu_period_us is 100 ms

So a container with 200m as limit, cannot use more than 200 milicpu at every 100 miliseconds.

Using CPU limits has some implications:

Protecting other containers

Ensures a container cannot use too much resources and affect others

CPU throttling

CPU under kubernetes is a compressible resource. When a container reaches that quota, it will have to wait to the next period (100 ms) to try to access to the CPU resources. This affects the performance and latency in the container and unwanted an uncontrolled situations can appear, like readiness or liveness probe failures.

Underutilization

Also, the node can have free CPU resources available, but they are not accesible by the limited container (underused) Not using CPU limits permits a better use of the CPU node resources

Some thougts and best practices¶

Always define CPU requests. This also avoids the qos class besteffort
In order to define a good value it is very important to have access to metrics about cpu consumption. Utilities like Goldilocks (vpa) o Robusta KRR can give recommendations.
Using CPU limits gives more importance to protect the nodes and other containers during high CPU usage and to having a controlled environment.
Some people recommends not using CPU limits and only use good CPU request values. It can also be disabled at kubelet level using cpuCFSQuota=0.
For pods that can have more that 1 replicas it can be useful to use horizontal pod autoescaler or Keda
For pods with only 1 replica, it can be useful to use vertical pod autoescaling
In some environments can be a good practice to change the cpu_period_us