Requests and Limits — Kubernetes

Resource requests are specified in the pod’s container spec. They inform the Kubernetes scheduler about the minimum CPU and memory required for a container to operate.

Based on these requests, the scheduler determines the most suitable node to place the pod, ensuring that each node has sufficient resources to meet the demands of its pods.

CPU limits to “limit” the amount of CPU a pod can access. This can help prevent a single pod from monopolizing all the CPU on a node.

However, before implementing CPU limits, it is crucial to understand how this mechanism works. CPU throttling and increased application latency can occur if limits are incorrectly set.

Create a manifest file and name it as request_deployment.yml

apiVersion: v1
kind: request
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: nginx
resources:
requests:
memory: "256Mi"
cpu: "0.5"

To set CPU requests and limits for the request_deployment file.

resources:
  requests:
    cpu: "256Mi"
  limits:
    cpu: "0.5"

Set the CPU request to 256Mi CPUs (100m) and the CPU limit to 0.5 milli CPUs.

Create the Pod

kubectl apply -f request_deployment.yml

Create a manifest file and name it as limit_range.yml

apiVersion: v1
kind: LimitRange
metadata:
  name: example-limitrange
  namespace: example-namespace
spec:
  limits:
  - type: Container
    max:
      cpu: "2"
      memory: 4Gi
    min:
      cpu: "100m"
      memory: 100Mi
    default:
      cpu: "500m"
      memory: 2Gi
    defaultRequest:
      cpu: "200m"
      memory: 1Gi

Quality of Service for Pods

When a pod is created, it receives an assigned quality-of-servicequality-of-service (QoS) class depending on its resource specifications. There are three classes of QoS:

• BestEffort → This class is assigned to a Pod that has containers without specified memory and CPU requests and limits.
• Burstable → A pod receives this assigned class if one of its containers has a specified memory or CPU request and limit.
• Guaranteed → A pod is assigned to this class if it meets the following conditions:

1. All containers in a pod have memory and CPU requests and limits.
2. All containers have memory requests equal to the limit.
3. All containers have CPU requests equal to the limit.

If Kubernetes unnecessarily reserves large amounts of resources, we might encounter frequentOOMerrors.

Out of Memory (OOM)

1. Exceeded Pod Memory Limits
2. Node Resource Pressure

Ways OOM Incidents

1. Incorrect Resource Requests and Limits
2. Memory Leaks
3. High Memory Usage

Strategies to Prevent OOM

1. Set Appropriate Resource Requests and Limits
2. Use Liveness and Readiness Probes
3. Monitor Memory Usage
4. Use Quality of Service (QoS) Classes
5. Automated Resource Management Tools

Probe Kubernetes 👈 Click the link

CPU throttlingis another consequence of failing to set (or) improperly setting CPU limits. When we specify a CPU limit, Kubernetes attaches a timeframe within which that CPU capacity is allowed.

buymeacoffee ☕ 👈 Click the link

If the container exceeds the limit before the cycle ends, it must pause and wait for the next cycle to begin before it can continue executing. This can lead to significant increases in response time.

Kubernetes errors 👈 Click the link

Best practices for CPU requests and limits

1. Set the CPU requests based on the application requirements.
2. Set the CPU limits based on the application performance.
3. Monitor the CPU usage of the containers.

Thank you 🙏 for taking the time to read our blog.