Kubernetes Resource Limits CPU Memory Format

💡 Quick Answer: CPU is specified in millicores (`200m` = 0.2 CPU, `500m` = 0.5 CPU, `1` = 1 full core). Memory is specified in bytes with suffixes (`256Mi` = 256 MiB, `1Gi` = 1 GiB). Set both `requests` (scheduling guarantee) and `limits` (hard cap) for every container.

The Problem

Kubernetes resource specifications use specific unit formats that are easy to get wrong. Common mistakes include confusing `Mi` with `M`, using wrong CPU units, or not understanding the difference between requests and limits — leading to OOMKilled pods, CPU throttling, or wasted cluster resources.

flowchart TB
    subgraph CPU["CPU Units"]
        M100["100m = 0.1 CPU"]
        M200["200m = 0.2 CPU"]
        M500["500m = 0.5 CPU"]
        C1["1 = 1 full core"]
        C2["2 = 2 full cores"]
    end
    subgraph MEM["Memory Units"]
        MI128["128Mi = 128 MiB"]
        MI256["256Mi = 256 MiB"]
        MI512["512Mi = 512 MiB"]
        GI1["1Gi = 1 GiB"]
        GI4["4Gi = 4 GiB"]
    end

The Solution

Resource Specification Syntax

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
    - name: app
      image: nginx
      resources:
        requests:          # Minimum guaranteed resources
          cpu: "200m"      # 0.2 CPU cores
          memory: "256Mi"  # 256 MiB RAM
        limits:            # Maximum allowed resources
          cpu: "500m"      # 0.5 CPU cores
          memory: "256Mi"  # 256 MiB RAM

CPU Units

Rule: `m` = millicores. 1 CPU = 1000m. Always use `m` suffix for consistency.

Memory Units

`Mi` vs `M` (Important!)

Always use `Mi`/`Gi` (binary). `256M` is ~4.6% less than `256Mi` — enough to cause unexpected OOMKilled.

Requests vs Limits

resources:
  requests:        # Scheduling: "I need at least this much"
    cpu: "200m"    # Scheduler finds a node with 200m available
    memory: "256Mi" # Scheduler finds a node with 256Mi available
  limits:          # Hard cap: "Never use more than this"
    cpu: "500m"    # CPU throttled above 500m (not killed)
    memory: "256Mi" # OOMKilled if exceeds 256Mi

QoS Classes

Kubernetes assigns QoS classes based on how you set requests and limits:

# Guaranteed QoS (recommended for production)
resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "500m"       # Same as request
    memory: "256Mi"   # Same as request

# Burstable QoS (allows bursting)
resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "500m"       # Higher than request
    memory: "512Mi"   # Higher than request

# BestEffort QoS (NOT recommended)
# No resources block at all

Common Patterns

# Web application
resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

# API server
resources:
  requests:
    cpu: "500m"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

# Database
resources:
  requests:
    cpu: "1"
    memory: "2Gi"
  limits:
    cpu: "2"
    memory: "4Gi"

# GPU workload
resources:
  requests:
    cpu: "4"
    memory: "16Gi"
  limits:
    cpu: "8"
    memory: "32Gi"
    nvidia.com/gpu: 1

Check Resource Usage

# Current resource requests and limits
kubectl describe pod <pod-name> | grep -A6 "Limits\|Requests"

# Actual resource usage
kubectl top pod <pod-name>
# NAME       CPU(cores)   MEMORY(bytes)
# my-app     145m         189Mi

# Node resource allocation
kubectl describe node <node> | grep -A5 "Allocated"
# CPU Requests: 4200m (52%), CPU Limits: 8000m (100%)
# Memory Requests: 6Gi (40%), Memory Limits: 12Gi (75%)

# Check QoS class
kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'
# Guaranteed

Common Issues

Best Practices

• Always set both requests AND limits — prevents BestEffort QoS
• Use `Mi`/`Gi` not `M`/`G` — binary units match how Linux reports memory
• Set memory requests = limits for Guaranteed QoS — prevents OOMKilled surprises
• Allow CPU bursting — CPU limits > requests lets pods burst during spikes
• Use VPA for right-sizing — let Vertical Pod Autoscaler recommend values
• Quote numeric values — `cpu: “1”` not `cpu: 1` to avoid YAML type issues

Key Takeaways

• CPU: millicores (`200m` = 0.2 cores, `1` = 1 core, `1000m` = 1 core)
• Memory: binary units (`256Mi`, `1Gi`) — always use `Mi`/`Gi`, not `M`/`G`
• Requests = scheduling guarantee, Limits = hard cap
• CPU is throttled above limit, Memory is OOMKilled above limit
• Guaranteed QoS (requests = limits) is safest for production workloads
• Use `kubectl top` and VPA to right-size resources based on actual usage