Resource Requirements

In this lesson we cover Kubernetes resource requests and limits, and how LimitRange and ResourceQuota affect scheduling, runtime behavior, and cluster capacity planning. You’ll learn how the scheduler uses these values to place pods, what happens when containers exceed their limits, and recommended practices for production clusters. Every node advertises an amount of CPU and memory. Each pod (more precisely, each container in a pod) can declare requests and limits. The scheduler uses requests to decide where to place pods. Once a pod is scheduled, requested resources are reserved for scheduling decisions and contribute to a container’s QoS classification. If a pod requests 2 CPUs and 1Gi of memory, the scheduler will only place it on a node with at least those available resources. If no node meets the requirements, the pod will remain in Pending and kubectl describe pod will show events such as “Insufficient cpu” or “Insufficient memory”.

A dark presentation slide titled "Resource Requests" with two colored blocks at the center-bottom showing resource labels: CPU (1) and MEM (1Gi) alongside a small cube icon.

Specifying Resource Requests

Add a resources section to the container spec with requests to specify the minimum CPU and memory the container requires:

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
  labels:
    name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "4Gi"
        cpu: "2"

In this example the container requests 4Gi of memory and 2 CPUs. The scheduler will place the pod only on a node that has those resources available; after scheduling, those requests influence QoS and eviction ranking.

CPU and Memory Units

CPU:
- Fractional values allowed (e.g., 0.1 CPU).
- 100m equals 0.1 CPU; the smallest accepted unit is 1m.
- 1 CPU typically maps to 1 vCPU or 1 core (provider-dependent).
Memory:
- Use unit suffixes like Ki, Mi, Gi or decimal K, M, G.
- Gi = 1024^3 bytes; G = 1000^3 bytes.

Resource	Example units	Notes
CPU	`100m`, `500m`, `1`	`1` ≈ 1 vCPU/core
Memory	`512Mi`, `1Gi`, `4Gi`	Prefer binary units `Mi`/`Gi` to avoid confusion

When to use `limits`

Setting requests ensures scheduling guarantees. To cap runtime consumption, add limits.

Without limits, a container can consume any available resources on the node (which may starve other pods).
With limits, CPU is throttled and memory overuse causes termination (OOM).

A slide titled "Resource Limits" showing two stacked columns comparing CPU (blue) and MEM (orange) with a dotted line marking "1 vCPU." A small cube icon and the labels "CPU" and "MEM" appear below, with a KodeKloud copyright in the corner.

Example with both requests and limits:

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
  labels:
    name: simple-webapp-color
spec:
  containers:
  - name: simple-webapp-color
    image: simple-webapp-color
    ports:
    - containerPort: 8080
    resources:
      requests:
        memory: "1Gi"
        cpu: "2"
      limits:
        memory: "2Gi"
        cpu: "2"

Requests and limits are defined per container. If a pod has multiple containers, each container declares its own requests and limits.

What happens when a container exceeds its limit?

CPU: the CFS scheduler throttles the container; it will not get more CPU cycles than the limit.
Memory: memory cannot be throttled. If a container exceeds its memory limit, the kernel may OOM-kill the process and the pod will be terminated.

A dark presentation slide titled "Exceed Limits" showing stacked blue CPU and orange MEM blocks with a "Throttle" button above. Dashed lines mark 2 vCPU and 2 Gi thresholds, with memory blocks extending past the 2 Gi line.

Under memory pressure, the kubelet may evict pods according to QoS and eviction thresholds to reclaim memory before an OOM occurs.

A slide titled "Exceed Limits" showing a stacked CPU vs MEM diagram with dotted lines marking 2 vCPU and 2 Gi thresholds. To the right are buttons labeled "Terminate" and "Out of Memory (OOM)," illustrating what happens when resource limits are exceeded.

Default configuration and common scenarios

By default, Kubernetes does not require requests or limits. Omitting them can cause noisy neighbors or unpredictable scheduling. The table below summarizes common combinations and their effects:

Scenario	Scheduler behavior	Runtime behavior
No requests, no limits	Pod schedulable anywhere with available capacity; no guarantees	Pod can use as much node resources as available (risky)
No requests, limits set	Effective request = limit for scheduling	CPU capped; memory capped (OOM if exceeded)
Requests and limits set	Scheduler respects `request` for placement	Container guaranteed `request`; cannot exceed `limit`
Requests set, no limits	Scheduler reserves `request`	CPU can burst above request (throttled if needed); memory can grow if available (risk of eviction/OOM under pressure)

A slide titled "Behavior – CPU" showing four side-by-side grid diagrams that compare CPU and memory allocation scenarios (No Requests/No Limits, No Requests/Limits, Requests/Limits, Requests/No Limits) with colored blocks and vCPU markers illustrating how requests and limits affect CPU usage.

Always set sensible resource requests for production workloads so the scheduler can place pods correctly. Use limits when you need to prevent runaway usage (e.g., multi-tenant clusters). If you want safe defaults or namespace restrictions, use LimitRange and ResourceQuota.

On shared clusters, omitting requests or limits may lead to unfair resource usage and evictions. Enforce namespace policies with LimitRange and ResourceQuota.

QoS classes (brief)

QoS classes influence eviction priority and are derived from requests/limits per pod:

Guaranteed: every container has CPU and memory requests equal to limits.
Burstable: at least one container has a request but not all request==limit.
BestEffort: no requests or limits specified.

Pods in BestEffort are the first to be evicted under resource pressure, while Guaranteed pods have the strongest eviction protection.

LimitRanges — defaults and min/max at namespace level

Use a LimitRange to provide defaults or enforce min/max values for containers in a namespace. LimitRange affects pods created or updated after it is applied. Example LimitRange (CPU and memory):

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - type: Container
    default:
      cpu: 500m
    defaultRequest:
      cpu: 500m
    max:
      cpu: "1"
    min:
      cpu: 100m
---
apiVersion: v1
kind: LimitRange
metadata:
  name: memory-resource-constraint
spec:
  limits:
  - type: Container
    default:
      memory: 1Gi
    defaultRequest:
      memory: 1Gi
    max:
      memory: 1Gi
    min:
      memory: 500Mi

Notes:

default applies when a container has no explicit limit.
defaultRequest applies when a container has no explicit request.
min/max restrict values for containers in the namespace.
Existing pods are not retroactively changed when a LimitRange is added.

ResourceQuota — namespace aggregate limits

ResourceQuota enforces hard caps on the total resource consumption within a namespace, limiting aggregate requests and limits.

A slide titled "Resource Quotas" showing a grid of CPU and MEM resource blocks for three nodes (Node 01, Node 02, Node 03). The rows are labeled NS1, NS2, and NS3 to represent namespaces across the nodes.

Example ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 4Gi
    limits.cpu: "10"
    limits.memory: 10Gi

This caps the sum of all containers’ requested CPU in the namespace to 4 CPUs and requested memory to 4Gi. It also limits total limits to 10 CPUs and 10Gi.

Practical tips

Always set at least requests for production workloads to avoid scheduling surprises.
Use limits to prevent noisy-neighbor problems in multi-tenant clusters.
Apply LimitRange to ensure consistent defaults and enforce min/max per namespace.
Apply ResourceQuota to enforce team-level resource budgets and prevent runaway consumption.
Monitor throttling and OOM events (kubectl describe pod, kubelet logs, and metrics) to tune requests and limits.

Wrap-up

Requests affect scheduling and guarantees.
Limits cap runtime usage (CPU throttled; memory OOM).
LimitRange provides namespace defaults and constraints.
ResourceQuota enforces namespace-level aggregate limits.

References

Kubernetes: Manage Resources for Containers — https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Kubernetes Quality of Service (QoS) — https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Resource Requirements

Specifying Resource Requests

CPU and Memory Units

When to use `limits`

What happens when a container exceeds its limit?

Default configuration and common scenarios

QoS classes (brief)

LimitRanges — defaults and min/max at namespace level

ResourceQuota — namespace aggregate limits

Practical tips

Watch Video

​Specifying Resource Requests

​CPU and Memory Units

​When to use limits

​What happens when a container exceeds its limit?

​Default configuration and common scenarios

​QoS classes (brief)

​LimitRanges — defaults and min/max at namespace level

​ResourceQuota — namespace aggregate limits

​Practical tips

Watch Video

Specifying Resource Requests

CPU and Memory Units

When to use `limits`

What happens when a container exceeds its limit?

Default configuration and common scenarios

QoS classes (brief)

LimitRanges — defaults and min/max at namespace level

ResourceQuota — namespace aggregate limits

Practical tips