Utilization of resources in a Pod

One of the key objectives addressed by Kubernetes is the efficient utilization of resources. All resources, such as memory and CPU, are limited and, in a cloud environment, for instance, incur costs. On the one hand, you must ensure that a node’s resources are maximally utilized. On the other hand, you must avoid starvation. In this topic, we look at requests and limits that help you strike this delicate balance.

Resource management

Every Pod is allocated a specific amount of CPU and memory resources that are utilized by the containers running inside the Pod. Since nodes in a cluster have limited resources such as CPU and memory, only a limited number of Pods can be deployed in a particular node. The kube-scheduler determines the ideal node to place a Pod based on available resources. To effectively schedule Pods, the kube-scheduler requires information about the resource demands for each Pod.

Here are the various resource types that a container needs:

• cpu — a unit of computing.

• memory — Random Access Memory (RAM).

• ephemeral-storage — local non-durable storage, for uses such as emptyDir volumes.

• hugepages-<side> — for Linux workloads, this allows the node to allocate memory blocks that are larger than the default page size.

CPU resources are measured in CPU units. 1 CPU unit is equivalent to 1 physical or virtual CPU core. However, you can also allocate a fraction of a CPU. For example, a request value of 0.5 means half as much CPU time compared to 1.0. 0.5 is also equivalent to 500m which is five hundred millicpu or milicores.

Memory resources are defined in bytes. Normally, the mebibyte value is used for memory, but you can use anything from bytes to petabytes. This also applies to ephemeral storage, which is backed by local storage devices on the node.

Requests and limits

Previously, we saw some crucial fields that go into our Pod’s specification. In addition to those fields, we can also optionally specify how much of a resource a specific container needs. Typically, resource configuration happens at the container level, but recently, you can also define overall Pod resources.

spec: 
  containers:
  - name: frontend
    image: nginx:latest
    imagePullPolicy: Always
 
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
        ephemeral-storage: "1Gi"
        
      limits:
        memory: "256Mi"
        cpu: "200m"
        ephemeral-storage: "2Gi"

      volumeMounts:
        - name: ephemeral-storage
          mountPath: "/tmp/logs"

    volumes:
    - name: ephemeral-storage
      emptyDir:
        sizeLimit: 500Mi

The requests field specifies the minimum amount of resources that a container needs to run. The kube-scheduler uses this information to determine the ideal node to place a Pod based on available resources. The Kubelet also reserves the requested resources for the container to use. However, if more resources exist, a Pod is permitted to use more than the requested amount.

While requests ensure that a container is guaranteed a certain amount of resources, limits specify the maximum amount that a Pod is allowed to use. With this information, the Kubelet ensures that a container doesn't exceed the specified resource limit. It is crucial to note that the limit can never be lower than the request.

When a container approaches its cpu limit, the kernel restricts its access to the CPU (throttling). Therefore, containers cannot use more CPU than is specified in their cpu limit. On the other hand, if an application uses more than its memory limit, the OOM killer may terminate it. However, this only happens if there is memory pressure. If there is more memory, the container would continue to run, but may get killed at any time.

QoS classes

The Kubelet uses Quality of Service (QoS) classes to determine which Pod to prioritize or remove when there is resource contention. The QoS class of a Pod is determined by its resource requests and limits defined in the Pod definition. There are three QoS classes in Kubernetes:

• Guaranteed;

• Burstable;

• BestEffort.

Pods in the Guaranteed class have both resource requests and limits specified for each container. Also, for every container in that Pod, resource limits must match the resource requests for each of those resources. These Pods have the highest priority, meaning they are the last ones to be evicted when there is resource contention. They are commonly used for critical workloads.

Pods in the BestEffort class have containers with no resource requests or limits specified. The Pod also has no Pod-level requests or limits set. Pods in this class can consume any amount of node resources. However, they have the lowest priority. This means they are the first to be evicted when there is contention for node resources. They are commonly used for non-critical workloads or background tasks.

Pods in the Burstable class have at least one container that has either resource requests or limits specified. This also applies if there are Pod-level requests or limits set. Since Pods in this class may include containers with no limits specified, they may strive to use any amount of node resources. Thus, when there is node contention (and all BestEffort Pods have been evicted), these Pods are next in line for termination and removal. Pods in this class have medium priority and are commonly used for applications that can tolerate occasional resource constraints.

Conclusion

Here, you learned how to configure container resources in Kubernetes. You now understand how to define resource requests, which reserve the necessary resources for a container, and resource limits, which set a cap on how much it can consume. Additionally, you discovered that Kubernetes automatically assigns Quality of Service (QoS) classes to Pods based on these settings. This assignment helps the Kubelet determine which workloads to prioritize or evict during times of resource contention.