CPU requests and limits in Kubernetes - Step-by-Step Execution

Process Flow - CPU requests and limits

Pod Spec Created

↓

CPU Requests Set?

No→Default Scheduler Behavior

Yes↓

Scheduler Checks Node Capacity

↓

Pod Scheduled on Node

↓

Container Starts Running

↓

CPU Usage Monitored

↓

CPU < Limit

↓

Runs Normally

The pod spec sets CPU requests and limits. Scheduler uses requests to place pods. Runtime enforces limits by throttling CPU if usage exceeds limit.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: "500m"
      limits:
        cpu: "1"

Defines a pod with CPU request of 0.5 CPU and limit of 1 CPU.

Process Table

Step	Action	CPU Request	CPU Limit	Scheduler Decision	Runtime Behavior
1	Pod spec created with CPU request 500m and limit 1	500m	1	Pending scheduling	Not started
2	Scheduler checks nodes for available CPU >= 500m	500m	1	Pod scheduled on node with enough CPU	Not started
3	Container starts running	500m	1	Scheduled	Container can use up to 1 CPU
4	Container CPU usage at 300m	500m	1	Scheduled	Runs normally, no throttling
5	Container CPU usage at 800m	500m	1	Scheduled	Runs normally, no throttling
6	Container CPU usage at 1200m	500m	1	Scheduled	CPU throttled to 1 CPU limit
7	Container CPU usage drops to 400m	500m	1	Scheduled	Runs normally, no throttling
8	Pod deleted or stopped	0	0	No scheduling	Container stopped

💡 Pod stops running or is deleted, ending CPU usage monitoring.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 6	After Step 8
CPU Request	None	500m	500m	500m	0
CPU Limit	None	1	1	1	0
CPU Usage	0	0	0	1200m	0
Pod State	Pending	Pending	Running	Running	Stopped
CPU Throttled	No	No	No	Yes	No

Key Moments - 3 Insights

Why does the scheduler use CPU requests and not limits to place pods?

The scheduler uses CPU requests as guaranteed minimum resources to ensure the node can handle the pod. Limits are enforced at runtime and do not affect scheduling decisions. See execution_table step 2.

What happens if the container tries to use more CPU than its limit?

The container is throttled by the runtime to not exceed the CPU limit, which means it cannot use more CPU than allowed. See execution_table step 6 where usage exceeds limit and throttling occurs.

Can a container use less CPU than its request?

Yes, the request is a minimum reserved amount, but the container can use less CPU if workload is low. See execution_table step 4 and 7 where usage is below request and runs normally.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the container start getting CPU throttled?

A Step 6

B Step 4

C Step 2

D Step 8

💡 Hint

Check the 'Runtime Behavior' column for when throttling starts.

According to the variable tracker, what is the CPU request value after step 3?

A 0

B 500m

C None

D 1

💡 Hint

Look at the 'CPU Request' row under 'After Step 3' column.

If the CPU limit was removed from the pod spec, how would the runtime behavior change at high CPU usage?

A Container would be throttled at 500m CPU

B Scheduler would fail to schedule the pod

C Container would never be throttled

D Pod would be deleted automatically

💡 Hint

Consider what happens when no CPU limit is set in the execution_table runtime behavior.

Concept Snapshot

CPU requests reserve minimum CPU for scheduling.
CPU limits cap max CPU usage at runtime.
Scheduler uses requests to place pods on nodes.
Runtime throttles CPU if usage exceeds limits.
Requests ensure guaranteed CPU, limits control max usage.

Full Transcript

In Kubernetes, CPU requests and limits control how pods use CPU resources. The CPU request is the minimum CPU the pod needs and is used by the scheduler to decide which node can run the pod. The CPU limit is the maximum CPU the pod can use at runtime. If the pod tries to use more CPU than its limit, the system throttles it to prevent overuse. The execution table shows a pod with 500m CPU request and 1 CPU limit. The scheduler places the pod on a node with enough CPU. The container runs normally when CPU usage is below the limit. When usage exceeds 1 CPU, throttling happens. Variables like CPU request, limit, usage, pod state, and throttling status change step by step. Key moments clarify why requests affect scheduling and limits affect runtime behavior. The quiz tests understanding of when throttling starts, CPU request values, and effects of removing limits.

Practice

1. What does setting a cpu request in a Kubernetes pod specification do?

easy

A. It guarantees a minimum amount of CPU for the container.

B. It limits the maximum CPU the container can use.

C. It sets the CPU priority for the container.

D. It reserves memory for the container.

Solution

1. Step 1: Understand CPU request meaning

   CPU request is the minimum CPU resource Kubernetes guarantees to a container.

2. Step 2: Differentiate from CPU limit

   CPU limit sets the maximum CPU usage, not the minimum guaranteed.

3. Final Answer:

   It guarantees a minimum amount of CPU for the container. -> Option A

4. Quick Check:

   CPU request = minimum CPU guaranteed [OK]

Hint: Requests guarantee minimum CPU, limits cap maximum CPU [OK]

Common Mistakes:

• Confusing CPU request with CPU limit
• Thinking requests set maximum CPU
• Mixing CPU with memory resource

2. Which of the following is the correct way to specify CPU requests and limits in a pod YAML?

easy

A. resources:
cpu:
request: 500m
limit: 1

B. resources:
requests:
cpu: 500
limits:
cpu: 1000

C. resources:
requests:
cpu: "500m"
limits:
cpu: "1"

D. resources:
requests:
cpu: "1.0"
limits:
cpu: "0.5"

Solution

1. Step 1: Check correct YAML structure for resources

   The correct keys are requests and limits under resources, with CPU values as strings with units like "500m" or "1".

2. Step 2: Validate resources: requests: cpu: "500m" limits: cpu: "1" format

   resources: requests: cpu: "500m" limits: cpu: "1" uses correct keys and units: "500m" means 0.5 CPU, "1" means 1 CPU core.

3. Final Answer:

   resources: requests: cpu: "500m" limits: cpu: "1" -> Option C

4. Quick Check:

   Correct YAML keys and CPU units = resources: requests: cpu: "500m" limits: cpu: "1" [OK]

Hint: Use 'requests' and 'limits' keys with CPU as string with units [OK]

Common Mistakes:

• Using 'request' instead of 'requests'
• Specifying CPU as numbers without quotes or units
• Mixing up 'cpu' and 'memory' keys

3. Given this pod spec snippet:

resources:
  requests:
    cpu: "200m"
  limits:
    cpu: "500m"

What happens if the container tries to use 600m CPU?

medium

A. The container will be killed immediately.

B. The container will be throttled to 500m CPU.

C. The container will be allowed to use 600m CPU.

D. The container will be throttled to 200m CPU.

Solution

1. Step 1: Understand CPU limit effect

   The CPU limit is the maximum CPU the container can use. Here it is 500m (0.5 CPU).

2. Step 2: Predict container behavior when exceeding limit

   If the container tries to use 600m CPU, Kubernetes throttles it to the limit, 500m CPU.

3. Final Answer:

   The container will be throttled to 500m CPU. -> Option B

4. Quick Check:

   CPU limit caps usage = throttled to 500m [OK]

Hint: CPU usage above limit gets throttled to limit [OK]

Common Mistakes:

• Thinking container can exceed CPU limit
• Confusing throttling with killing container
• Assuming CPU request is the max limit

4. You wrote this pod spec:

resources:
  requests:
    cpu: "100m"
  limits:
    cpu: "50m"

What is wrong with this configuration?

medium

A. CPU requests and limits cannot be set together.

B. CPU request is less than CPU limit, which is invalid.

C. CPU values must be integers, not strings.

D. CPU limit is less than CPU request, which is invalid.

Solution

1. Step 1: Compare CPU request and limit values

   CPU request is 100m (0.1 CPU), CPU limit is 50m (0.05 CPU).

2. Step 2: Validate Kubernetes rules for requests and limits

   CPU limit must be equal or greater than CPU request. Here limit < request, which is invalid.

3. Final Answer:

   CPU limit is less than CPU request, which is invalid. -> Option D

4. Quick Check:

   Limit >= Request rule violated = CPU limit is less than CPU request, which is invalid. [OK]

Hint: Limit must be >= request, else config is invalid [OK]

Common Mistakes:

• Setting limit less than request
• Thinking CPU values must be integers
• Believing requests and limits can't coexist

5. You want to ensure a container always gets at least 250m CPU but never uses more than 750m CPU. Which YAML snippet correctly sets this with CPU requests and limits?

hard

A. resources:
requests:
cpu: "250m"
limits:
cpu: "750m"

B. resources:
requests:
cpu: "750m"
limits:
cpu: "250m"

C. resources:
requests:
cpu: 0.25
limits:
cpu: 0.75

D. resources:
requests:
cpu: "0.75"
limits:
cpu: "0.25"

Solution

1. Step 1: Identify correct CPU units and values

   CPU values can be specified as millicores with 'm' suffix, e.g., "250m" for 0.25 CPU.

2. Step 2: Check request and limit order

   Request must be less than or equal to limit. resources: requests: cpu: "250m" limits: cpu: "750m" sets request to 250m and limit to 750m correctly.

3. Final Answer:

   resources: requests: cpu: "250m" limits: cpu: "750m" -> Option A

4. Quick Check:

   Request 250m ≤ Limit 750m with correct units = resources: requests: cpu: "250m" limits: cpu: "750m" [OK]

Hint: Use millicores with 'm' and keep request ≤ limit [OK]

Common Mistakes:

• Swapping request and limit values
• Using decimal numbers without quotes
• Not using millicores for fractional CPU