Understanding CPU Requests and Limits in Kubernetes: What “1 CPU” Really Means?

Introduction

In Kubernetes, setting CPU requests and limits in a pod manifest is crucial for managing how much CPU time each container can use. But does specifying “1 CPU” mean that an entire CPU core from the worker node is dedicated to the pod?

When I first started working with Kubernetes, I was also confused about what exactly happens when you specify “1 CPU” in a pod’s manifest. At first glance, it might seem like Kubernetes is assigning a whole CPU core exclusively to your container. However, that’s not quite the case. Setting CPU requests and limits in Kubernetes actually means controlling CPU time, rather than reserving dedicated physical cores.

In this post, we will dive into what CPU requests and limits really mean and clarify the difference. Understanding these concepts can make a big difference in how efficiently your applications run in a Kubernetes environment.

What Do CPU Requests and Limits Represent?

When we define CPU resources in Kubernetes, we are actually specifying CPU time slices rather than physical cores. Here is how it breaks down:

• CPU Request: This is the minimum guaranteed CPU time Kubernetes will reserve for a container, even during high demand.
• CPU Limit: This is the maximum CPU time the container can use. If the container tries to go above this limit, Kubernetes will throttle it to prevent overuse.

Example: Specifying CPU Requests and Limits

Consider the following pod configuration:

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: nginx
    resources:
      requests:
        cpu: "500m"    # 0.5 CPU
      limits:
        cpu: "1"       # 1 CPU

In this example:

• CPU Request(500m): Ensures the container receives a guaranteed 50% of a CPU core’s worth of time on the node.
• CPU Limit(1): Sets a cap of 1 CPU, meaning the container cannot use more than a full CPU’s worth of time, even if other CPU resources are available.

Does 1 CPU Mean a Dedicated CPU Core?

No. Setting 1 CPU as a limit or request doesn’t mean one physical core is exclusively reserved for this pod. Instead, it indicates that the container can consume up to the equivalent time of one CPU core. i.e. you are asking for the equivalent processing power of one full CPU core over time. This is managed by the Linux CPU scheduler. Linux handles these allocations with time-sharing, switching processes in and out of available cores so that each process gets a fair share.

Visualization

Imagine three containers on a 4-core node:

• Container A with 500m request and 1 limit.
• Container B with 1 request and 2 limit.
• Container C with 200m request and 500m limit.

Each container receives at least its requested amount of CPU time, and none will exceed their limits, even if CPU resources are available. Kubernetes and Linux enforce these boundaries by scheduling CPU time slices instead of assigning dedicated cores.

Key Takeaways

• CPU requests guarantee a minimum CPU allocation, ensuring essential workloads don’t starve for resources.
• CPU limits prevent a container from exceeding a set CPU usage, maintaining node balance.
• Specifying 1 CPU does not mean a dedicated core but rather a cap on the allowed CPU time across available cores.

Understanding CPU requests and limits helps you effectively manage resource allocation in Kubernetes, ensuring efficient and stable operations across your cluster.