Mastering Kubernetes Limits & Requests: Best Practices and Real‑World Examples

Kubernetes Limits and Requests Overview

When using containers in Kubernetes, it is important to know the resources each process needs; some processes require more CPU or memory and some are critical and must not be starved.

Therefore we should configure containers and Pods correctly to achieve optimal results.

Practical Example

Consider a Deployment with two containers (redis and busybox) where we set specific limits and requests for CPU and memory.

kind: Deployment
apiVersion: extensions/v1beta1
...
template:
  spec:
    containers:
    - name: redis
      image: redis:5.0.3-alpine
      resources:
        limits:
          memory: 600Mi
          cpu: 1
        requests:
          memory: 300Mi
          cpu: 500m
    - name: busybox
      image: busybox:1.28
      resources:
        limits:
          memory: 200Mi
          cpu: 300m
        requests:
          memory: 100Mi
          cpu: 100m

If we schedule this deployment on a 4CPU‑16Gi node, we can derive the following observations:

Pod's effective request is 400Mi memory and 600 millicores CPU; a node must have enough allocatable space.

Redis container gets 512 CPU shares, busybox gets 102 (Kubernetes assigns 1024 shares per core).

If Redis exceeds its 600Mi memory limit it will be OOM‑killed, possibly causing pod failure.

If Redis tries to use more than 100ms of CPU per 100ms interval (given 4 cores = 400ms), it will be throttled.

If Busybox exceeds its 200Mi memory limit it will be OOM‑killed.

If Busybox exceeds 30ms CPU per 100ms interval it will be throttled.

Kubernetes Requests

Requests define the minimum guaranteed amount of resources a container will receive.

When a Pod is scheduled, the kube‑scheduler ensures the node can satisfy all containers' requests; otherwise the Pod remains Pending.

Example request definition (100m CPU, 4Mi memory):

resources:
  requests:
    cpu: 0.1
    memory: 4Mi

Requests are typically used when you need to guarantee a resource share for a process.

When assigning a Pod to a node, the specified requests must be satisfied.

At runtime, the requested amount is guaranteed as the container's minimum.

Kubernetes Limits

Limits define the maximum amount of resources a container may use; consumption cannot exceed these values.

resources:
  limits:
    cpu: 0.5
    memory: 100Mi

Limits are used when no explicit request is set (default request = limit) and the runtime enforces the cap.

If a Pod is assigned to a node without a request, Kubernetes defaults request = limit.

During execution, the system checks whether consumption exceeds the defined limits.

CPU Characteristics

CPU is a compressible resource; it can be throttled if a process asks for too much.

CPU is measured in cores; fractions can be expressed in millicores (e.g., 500m = 0.5 core). The smallest unit is 1m, and requests greater than 1 are possible on multi‑core nodes.

Memory Characteristics

Memory is an incompressible resource; insufficient memory causes the process to be killed.

Memory units are bytes; common prefixes are Ki, Mi, Gi, Ti, Pi, Ei. Do not use lowercase “m” for memory.

Best Practices

Prefer using requests over limits to avoid starvation; limits only prevent occasional over‑consumption that could cause OOM or CPU throttling.

Setting limits equal to requests guarantees QoS for the Pod, but overly low requests increase eviction risk.

Namespace ResourceQuota

ResourceQuota isolates resources per namespace (tenant) by setting aggregate CPU and memory caps.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: 2
    requests.memory: 1Gi
    limits.cpu: 3
    limits.memory: 2Gi

requests.cpu – maximum total CPU requests in the namespace.

requests.memory – maximum total memory requests.

limits.cpu – maximum total CPU limits.

limits.memory – maximum total memory limits.

Apply with kubectl apply -f resourcequota.yaml --namespace=mynamespace and list with kubectl get resourcequota -n mynamespace. Exceeding quotas results in “failed quota” or “exceeded quota” errors.

Namespace LimitRange

LimitRange provides default, minimum, and maximum resource settings for each container in a namespace.

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

default – value applied when none is specified.

min – smallest allowed request or limit.

max – largest allowed request or limit.

If a Pod is created without explicit requests or limits, the LimitRange automatically injects these values.

Summary

Choosing appropriate limits for a Kubernetes cluster is crucial for energy efficiency and cost control. Over‑allocating resources drives up cost, while under‑allocating can cause application failures or pod eviction. Use requests to guarantee resource shares and limits sparingly to avoid OOM kills or CPU throttling.

References

https://sysdig.com/blog/kubernetes-pod-pending-problems/

https://sysdig.com/blog/troubleshoot-kubernetes-oom/

https://sysdig.com/blog/kubernetes-pod-evicted/

https://sysdig.com/blog/kubernetes-limits-requests/