> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Resource Requirements

> Explains Kubernetes resource requests, limits, units, scheduler behavior, defaults, and namespace controls using LimitRange and ResourceQuota to ensure predictable CPU and memory usage.

This guide explains how Kubernetes uses resource requests and limits to schedule and enforce CPU and memory for workloads. It covers units, scheduler behavior, defaults and best practices, and how to enforce namespace-level constraints with LimitRange and ResourceQuota.

We begin with a simple three-node cluster: each node advertises available CPU and memory capacity, and each pod consumes some of that capacity. For example, a pod that requests two CPUs and one unit of memory reduces the available resources on the node where the scheduler places it.

![A schematic diagram of three server nodes (Node 01, Node 02, Node 03), each showing stacked CPU and memory (MEM) resource blocks. A small legend with colored gradient bars and a container icon appears above the nodes.](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/three-server-nodes-cpu-memory-diagram.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=caca31f5ff0eeb62c73044eab5c74fb8)

When scheduling a pod, the Kubernetes scheduler compares the pod’s resource requests against node capacity. If no node can satisfy the requests, the pod stays in Pending. Inspecting a pending pod with `kubectl describe pod` will show events such as "Insufficient cpu" or "Insufficient memory".

## Requests vs Limits — high-level

* Request: the minimum amount of CPU or memory a container needs. The scheduler uses requests to place pods.
* Limit: the maximum amount a container may use at runtime. The kubelet and kernel enforce limits.

## Resource requests

A resource request is the guaranteed minimum the scheduler uses to reserve capacity for a container. For example, a container might request `1` CPU and `1Gi` memory.

![A slide titled "Resource Requests" on a dark blue background showing a small cube icon and two rounded cards labeled "CPU" (1) and "MEM" (1Gi).](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/resource-requests-cpu-1-mem-1gi.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=888969332b6cd19cac22fedaf6fb340b)

Example: specify requests in a pod manifest (this container requests 2 CPUs and 4 Gi of memory):

```yaml theme={null}
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"
```

## CPU and memory units

CPU and memory support different unit formats; picking the right one prevents surprises.

* CPU
  * Whole numbers (e.g., `1`, `2`) or millicores (e.g., `100m` = 0.1 CPU).
  * Smallest unit is `1m`.
  * One CPU typically maps to one AWS vCPU, one GCP core, one Azure core, or one hyperthread depending on the environment.

![A dark presentation slide titled "Resource — CPU" with a blue CPU icon and a block labeled "CPU" showing the value 1. A bullet list to the right defines that 1 CPU equals 1 AWS vCPU, 1 GCP Core, 1 Azure Core, or 1 Hyperthread.](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/cpu-1-equivalent-vcpu-core-hyperthread.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=a1a0996ba44eeac2be1b509412cb3608)

* Memory
  * Supports binary suffixes (`Ki`, `Mi`, `Gi`) and decimal suffixes (`K`, `M`, `G`).
  * `Gi` is gibibyte (1024^3 bytes); `G` is gigabyte (1000^3 bytes).
  * Use binary units (`Mi`, `Gi`) for precise sizing when needed.

![A presentation slide titled "Resource – Memory" with a stylized memory block labeled "MEM" and "1G." To the right are bullet points listing decimal and binary unit definitions (G, M, K and Gi, Mi, Ki) with their byte values.](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/resource-memory-decimal-binary-units.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=389030443d23e52aff06a420250d1132)

## Resource limits

If no limits are set, a container can consume up to the node’s available resources. Limits let you cap usage so workloads cannot exceed defined CPU or memory values.

Example pod with both requests and limits — requests guarantee a minimum while limits cap the maximum:

```yaml theme={null}
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"
```

![An infographic titled "Resource Limits" showing two stacked columns of rounded blocks representing CPU (blue) and MEM (orange). A dashed line labels "1 vCPU" across the CPU column and a small container icon sits below.](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/resource-limits-cpu-mem-1vcpu-container.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=52a9c4b91a68980c7213a3717baad325)

## CPU vs Memory behavior when exceeding limits

* CPU: when a container exceeds its CPU limit, the kernel throttles CPU usage so it cannot run above the configured limit.
* Memory: memory cannot be throttled. If a container uses more memory than its limit and the node cannot free memory, the kernel’s OOM killer may terminate the container. You will see `OOMKilled` in pod status or events when this happens.

![A slide titled "Exceed Limits" shows stacked blocks for CPU and MEM with dashed lines marking 2 vCPU and 2 Gi thresholds. To the right are two buttons labeled "Terminate" and "Out of Memory (OOM)."](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/exceed-limits-2vcpu-2gi-terminate-oom.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=c57075f2cb3ebffc8179bd392d3a5eff)

Memory limits are strict: if a container exceeds its memory limit and the system cannot reclaim memory, the container may be killed (OOMKilled). Always size memory conservatively and monitor OOM events.

## Default behavior and recommended practices

Kubernetes does not automatically set requests or limits unless you configure objects such as LimitRange. Without requests, the scheduler cannot reserve resources and a single pod can monopolize node resources.

Common scenarios and their implications:

| Scenario | Scheduler behavior | Runtime behavior | When to use |
| - | -: | - | - |
| No requests and no limits | Scheduler has no guaranteed capacity to reserve | Pod can consume as much as node allows — risk of contention | Avoid for production workloads |
| Limits set but no requests | Kubernetes sets the request equal to the limit | Scheduler reserves the full limit; runtime is capped | Use when you want guaranteed and capped resources |
| Requests and limits set | Scheduler reserves the requested amount; runtime capped at limit | Guaranteed minimum with an enforced maximum | Safe and predictable for critical services |
| Requests set but no limits | Scheduler reserves the request; runtime can burst if spare capacity exists | Pod may use additional CPU/memory until node contention | Often preferred for CPU-bursting workloads (memory risk if unbounded) |

![An infographic titled "Behavior — CPU" showing four side-by-side scenarios of CPU and memory allocation under different combinations of requests and limits. Each column uses colored blocks in CPU and MEM grids to illustrate how vCPU allocation changes when requests and/or limits are set.](https://mintcdn.com/kodekloud-c4ac6d9a/szXnfDEgCPpDiwaI/images/Certified-Kubernetes-Administrator-CKA/Scheduling/Resource-Requirements/cpu-behavior-vcpu-requests-limits.jpg?fit=max\&auto=format\&n=szXnfDEgCPpDiwaI\&q=85\&s=11d31f1da12105be6fc0a53e59444fdd)

Tip: For CPU, it is common to set requests and leave limits unset to allow bursty workloads to use unallocated CPU. For memory, set both requests and limits when possible because memory overuse can trigger OOM kills.

## LimitRanges — namespace defaults and constraints

Use a LimitRange to provide namespace-level defaults, minimums, and maximums for container `requests` and `limits`. LimitRanges only apply to pods created after the LimitRange is added or updated; they do not mutate existing pods.

Example LimitRange for CPU:

```yaml theme={null}
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
```

Example LimitRange for memory:

```yaml theme={null}
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
```

LimitRanges are applied at the namespace level and affect only new pods created after the LimitRange is in place. They help enforce sensible defaults and prevent runaway resource usage.

## ResourceQuota — cap total consumable resources per namespace

ResourceQuota enforces a hard limit on the aggregate resources a namespace can consume (requests, limits, object counts, etc.). This is useful for multi-tenant clusters or to prevent a namespace from exhausting cluster-wide resources.

Example ResourceQuota limiting aggregate requests and limits:

```yaml theme={null}
apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "4Gi"
    limits.cpu: "10"
    limits.memory: "10Gi"
```

This example caps the total requested CPU in the namespace to 4 CPUs and requested memory to 4 GiB, while allowing a higher ceiling for limits across all objects in that namespace.

## Conclusion

Requests and limits make resource consumption predictable and protect cluster stability:

* Use requests so the scheduler can place pods correctly.
* Use limits to prevent runaway resource usage and protect node stability.
* Use LimitRange to provide sensible defaults and bounds at the namespace level.
* Use ResourceQuota to control the total resources a namespace may consume.

Try these manifests in a lab cluster to observe how requests, limits, LimitRanges, and ResourceQuotas interact in practice.

Links and references

* Kubernetes Documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/)
* Scheduler concepts: [https://kubernetes.io/docs/concepts/scheduling-eviction/](https://kubernetes.io/docs/concepts/scheduling-eviction/)
* Resource quotas: [https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/)

> **[Watch Video](https://learn.kodekloud.com/user/courses/cka-certification-course-certified-kubernetes-administrator/module/cd124bdf-9911-4cc1-8177-f2d8b6dfd2a0/lesson/b8157a80-d829-43ae-a8a0-86175db24836)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.