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

Process Flow - Resource requests and limits

Pod Spec Created

↓

Define Resource Requests

↓

Define Resource Limits

↓

Pod Scheduled on Node

↓

Kubelet Enforces Limits

↓

Container Runs with Guaranteed Resources

↓

Monitor Usage and Adjust if Needed

This flow shows how Kubernetes uses resource requests and limits to schedule and run pods with guaranteed CPU and memory.

Execution Sample

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

This pod requests 64Mi memory and 250m CPU, with limits set to 128Mi memory and 500m CPU.

Process Table

Step	Action	Resource Requests	Resource Limits	Scheduler Decision	Kubelet Enforcement
1	Pod Spec Created	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Pending	Not applied yet
2	Scheduler Checks Node Capacity	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Node selected with enough resources	Not applied yet
3	Pod Scheduled on Node	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Scheduled	Not applied yet
4	Kubelet Starts Container	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Running	Limits enforced: max 128Mi memory, 500m CPU
5	Container Runs	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Running	CPU throttled if >500m, OOM kill if >128Mi memory
6	Resource Usage Monitored	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Running	Adjust requests/limits if needed
7	Pod Deleted or Completed	memory=64Mi, cpu=250m	memory=128Mi, cpu=500m	Terminated	Resources freed

💡 Pod lifecycle ends when container stops or pod is deleted

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
memory_request	undefined	64Mi	64Mi	64Mi	64Mi
cpu_request	undefined	250m	250m	250m	250m
memory_limit	undefined	128Mi	128Mi	128Mi	128Mi
cpu_limit	undefined	500m	500m	500m	500m
pod_status	Pending	Pending	Running	Running	Terminated

Key Moments - 3 Insights

Why does the pod stay in Pending state even if the resource requests are low?

The pod stays Pending until the scheduler finds a node with enough available resources to meet the requests, as shown in step 2 of the execution_table.

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

Kubelet throttles the CPU usage to the limit (500m in this example), preventing the container from using more CPU, as shown in step 5.

Can a container use less than its requested resources?

Yes, requests are minimum guaranteed resources, but the container can use less if available, as requests affect scheduling but not enforcement.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What is the pod's status?

A Scheduled

B Running

C Pending

D Terminated

💡 Hint

Check the 'Scheduler Decision' column at step 3 in the execution_table.

At which step does the kubelet start enforcing resource limits?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Kubelet Enforcement' column to see when limits are applied.

If the memory limit was lowered to 64Mi, what would happen at step 5?

A Container could use up to 128Mi memory

B Container could be OOM killed if it uses more than 64Mi memory

C Scheduler would reject the pod

D CPU limits would be ignored

💡 Hint

Refer to step 5's 'Kubelet Enforcement' about memory limits and OOM kill.

Concept Snapshot

Resource requests specify minimum CPU and memory guaranteed for a pod.
Resource limits specify maximum CPU and memory a pod can use.
Scheduler uses requests to place pods on nodes with enough resources.
Kubelet enforces limits during container runtime.
Exceeding limits can cause throttling (CPU) or termination (memory).
Requests and limits help ensure stable cluster resource usage.

Full Transcript

In Kubernetes, resource requests and limits control how much CPU and memory a pod can use. The pod spec defines requests as the minimum resources needed, and limits as the maximum allowed. When a pod is created, the scheduler looks for a node with enough free resources to meet the requests. Once scheduled, the kubelet enforces the limits during container runtime. If a container tries to use more CPU than its limit, it is throttled. If it uses more memory than its limit, it can be terminated by the system. This mechanism helps keep the cluster stable and fair for all workloads.

Practice

1. What does setting a resource request for a container in Kubernetes guarantee?

easy

A. The container will get at least the requested CPU and memory resources.

B. The container can never use more than the requested resources.

C. The container will be restarted if it uses more than the requested resources.

D. The container will share resources equally with all other containers.

Solution

1. Step 1: Understand resource requests in Kubernetes

   Resource requests specify the minimum CPU and memory a container needs to run properly.

2. Step 2: Clarify what is guaranteed by requests

   Kubernetes ensures the container gets at least the requested resources but does not limit usage to that amount.

3. Final Answer:

   The container will get at least the requested CPU and memory resources. -> Option A

4. Quick Check:

   Resource request = minimum guaranteed resources [OK]

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

Common Mistakes:

• Confusing requests with limits
• Thinking requests cap usage
• Assuming requests cause restarts

2. Which of the following is the correct way to specify CPU and memory requests in a Kubernetes Pod YAML?

easy

A. resources:
requests:
cpu: "0.5"
memory: "256MB"

B. resources:
limits:
cpu: 500
memory: 256

C. resources:
requests:
cpu: 500m
memory: 256MiB

D. resources:
requests:
cpu: "500m"
memory: "256Mi"

Solution

1. Step 1: Review correct syntax for resource requests

   CPU requests use millicores with "m" suffix as string, memory uses Mi or Gi units as string.

2. Step 2: Identify correct option

   resources: requests: cpu: "500m" memory: "256Mi" uses "500m" for CPU and "256Mi" for memory correctly as strings.

3. Final Answer:

   resources: requests: cpu: "500m" memory: "256Mi" -> Option D

4. Quick Check:

   CPU in millicores and memory in Mi with quotes [OK]

Hint: Use quotes and correct units like "500m" and "256Mi" [OK]

Common Mistakes:

• Omitting quotes around resource values
• Using wrong units like MB instead of Mi
• Specifying CPU as plain number without m

3. Given this Pod spec snippet, what is the maximum CPU the container can use?

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

medium

A. 500 millicores

B. 200 millicores

C. 700 millicores

D. Unlimited CPU

Solution

1. Step 1: Understand CPU requests and limits

   Requests set minimum guaranteed CPU, limits set maximum allowed CPU usage.

2. Step 2: Identify maximum CPU from limits

   The limit is "500m", meaning 500 millicores is the max CPU the container can use.

3. Final Answer:

   500 millicores -> Option A

4. Quick Check:

   CPU limit = max CPU usage [OK]

Hint: Limits define max usage, requests define minimum [OK]

Common Mistakes:

• Confusing requests with limits
• Adding requests and limits incorrectly
• Assuming no max limit if requests set

4. You set a memory limit of 256Mi but forgot to set a memory request. What is the likely effect on your Pod scheduling?

medium

A. The Pod will use unlimited memory since request is missing.

B. The Pod may be scheduled with no guaranteed memory, risking eviction under pressure.

C. The Pod will be scheduled with 256Mi guaranteed memory automatically.

D. The Pod will fail to start due to missing memory request.

Solution

1. Step 1: Understand default behavior when requests are missing

   If memory request is not set, Kubernetes treats it as zero, meaning no guaranteed memory.

2. Step 2: Effect on scheduling and eviction

   Pod may be scheduled but can be evicted if node memory is low because it has no guaranteed reservation.

3. Final Answer:

   The Pod may be scheduled with no guaranteed memory, risking eviction under pressure. -> Option B

4. Quick Check:

   Missing request means no guaranteed resources [OK]

Hint: Always set requests to guarantee resources and avoid eviction [OK]

Common Mistakes:

• Assuming limits imply requests
• Thinking Pod fails without requests
• Believing missing requests mean unlimited resources

5. You want to ensure a container always has at least 100m CPU and 128Mi memory but never uses more than 300m CPU and 256Mi memory. Which is the correct resource configuration snippet?

hard

A. resources:
requests:
cpu: "300m"
memory: "256Mi"
limits:
cpu: "100m"
memory: "128Mi"

B. resources:
limits:
cpu: "100m"
memory: "128Mi"
requests:
cpu: "300m"
memory: "256Mi"

C. resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "300m"
memory: "256Mi"

D. resources:
requests:
cpu: "100"
memory: "128"
limits:
cpu: "300"
memory: "256"

Solution

1. Step 1: Match minimum guaranteed resources to requests

   Requests must be set to 100m CPU and 128Mi memory to guarantee minimum.

2. Step 2: Match maximum allowed resources to limits

   Limits must be set to 300m CPU and 256Mi memory to cap usage.

3. Step 3: Verify correct syntax and order

   resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "300m" memory: "256Mi" correctly sets requests first, then limits with proper units and quotes.

4. Final Answer:

   resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "300m" memory: "256Mi" -> Option C

5. Quick Check:

   Requests = min, Limits = max with correct units [OK]

Hint: Requests are min, limits are max; use correct units and quotes [OK]

Common Mistakes:

• Swapping requests and limits
• Omitting units or quotes
• Using plain numbers without units