Resource requests and limits in Kubernetes - Commands & Configuration

Introduction

When you run applications in Kubernetes, you need to tell the system how much CPU and memory your app needs. Resource requests and limits help Kubernetes decide how to share the computer's power fairly and keep apps running smoothly without crashing or slowing down.

When you want to make sure your app always gets enough CPU and memory to work well.

When you want to stop one app from using too much CPU or memory and slowing down others.

When you want Kubernetes to schedule your app only on nodes that have enough free resources.

When you want to avoid your app being killed because it uses too much memory.

When you want to optimize your cluster's resource usage and avoid wasting CPU or memory.

Config File - pod.yaml

pod.yaml

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

This YAML file creates a pod named resource-demo-pod with one container running the nginx image.

The resources section sets requests and limits for CPU and memory:

• requests tell Kubernetes the minimum resources the container needs to start and run.
• limits set the maximum resources the container can use.

Here, the container requests 64Mi memory and 250m CPU (0.25 CPU cores), and limits are 128Mi memory and 500m CPU (0.5 CPU cores).

Commands

This command creates the pod with the resource requests and limits defined in the pod.yaml file.

Terminal

kubectl apply -f pod.yaml

Expected Output

pod/resource-demo-pod created

This command shows the status and details of the pod to confirm it is running with the specified resources.

Terminal

kubectl get pods resource-demo-pod -o wide

Expected Output

NAME               READY   STATUS    RESTARTS   AGE   IP           NODE           NOMINATED NODE   READINESS GATES

resource-demo-pod   1/1     Running   0          10s   10.244.1.5   worker-node-1   <none>           <none>

→

-o wide - Shows extra details like IP and node name

This command shows detailed information about the pod, including the resource requests and limits set for the container.

Terminal

kubectl describe pod resource-demo-pod

Expected Output

Name:         resource-demo-pod

Namespace:    default

Priority:     0

Node:         worker-node-1/192.168.1.10

Start Time:   Thu, 01 Jun 2023 10:00:00 +0000

Labels:       <none>

Annotations:  <none>

Status:       Running

IP:           10.244.1.5

Containers:

  demo-container:

    Container ID:   docker://abcdef123456

    Image:          nginx

    Image ID:       docker-pullable://nginx@sha256:abcdef1234567890

    Port:           <none>

    Host Port:      <none>

    State:          Running

      Started:      Thu, 01 Jun 2023 10:00:05 +0000

    Ready:          True

    Restart Count:  0

    Limits:

      cpu:     500m

      memory:  128Mi

    Requests:

      cpu:        250m

      memory:     64Mi

Conditions:

  Type              Status

  Initialized       True 

  Ready             True 

  ContainersReady   True 

  PodScheduled      True 

Volumes:            <none>

QoS Class:          Burstable

Node-Selectors:     <none>

Tolerations:        <none>

Events:             <none>

Key Concept

If you remember nothing else from this pattern, remember: resource requests reserve minimum CPU and memory for your app, and limits cap the maximum your app can use to keep the system stable.

Common Mistakes

Setting resource limits lower than requests

Kubernetes will reject the pod because limits must be equal or higher than requests.

Always set limits equal to or higher than requests for both CPU and memory.

Not setting any resource requests or limits

The pod may get scheduled on a node without enough resources or use too much CPU/memory, causing instability.

Always define at least resource requests to help Kubernetes schedule your pod properly.

Using too high resource requests unnecessarily

This wastes cluster resources and may prevent other pods from scheduling.

Set requests based on actual app needs, not just maximum possible usage.

Summary

Create a pod YAML file with resource requests and limits under the container's resources section.

Apply the pod configuration using kubectl apply -f pod.yaml to create the pod.

Check the pod status and details with kubectl get pods and kubectl describe pod to verify resource settings.

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