Skip to main content
RunBook Academy

KubernetesCIX · LimitRangeLimitRange

LimitRange overview — defaults and constraints per container and Pod

Advanced⏱ ~16 minkubectl

What you'll learn

  • Use LimitRange for per-container defaults and constraints
  • Configure per-Pod and per-PVC constraints
  • Reason about the relationship to ResourceQuota
  • Apply the operational discipline of using LimitRange alongside ResourceQuota

Prerequisites

Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16

Not yet marked complete on this device.

LimitRange provides per-container defaults and constraints. This lesson walks the LimitRange types, the relationship to ResourceQuota, and the operational discipline.

The four LimitRange types

flowchart LR
    A[LimitRange] --> B[Container]
    A --> C[Pod]
    A --> D[PersistentVolumeClaim]
    A --> E[PersistentVolume]

The four types:

  • Container. Defaults and constraints per container (most common).
  • Pod. Constraints across all containers in a Pod (e.g., max CPU sum).
  • PersistentVolumeClaim. Defaults and constraints per PVC.
  • PersistentVolume. Min/max for PVs (less common).

A Container LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: container-limits
  namespace: tenant-a-prod
spec:
  limits:
    - type: Container
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      max:
        cpu: 2
        memory: 4Gi
      min:
        cpu: 50m
        memory: 64Mi
      maxLimitRequestRatio:
        cpu: "4"
        memory: "2"

The fields:

  • default. Limits applied to containers that don’t specify them.
  • defaultRequest. Requests applied to containers that don’t specify them.
  • max. Maximum limits a container can request.
  • min. Minimum requests a container must request.
  • maxLimitRequestRatio. The maximum ratio of limit to request (prevents massive overcommit).

A Pod LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: pod-limits
  namespace: tenant-a-prod
spec:
  limits:
    - type: Pod
      max:
        cpu: 4
        memory: 8Gi
      min:
        cpu: 100m
        memory: 128Mi

The Pod LimitRange bounds the sum of all containers in a Pod. A Pod with two containers, each requesting 2 cores, would exceed the Pod max of 4 cores.

A PVC LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: pvc-limits
  namespace: tenant-a-prod
spec:
  limits:
    - type: PersistentVolumeClaim
      max:
        storage: 100Gi
      min:
        storage: 1Gi

The PVC LimitRange bounds the storage request per PVC. A PVC requesting 200Gi would be rejected.

The relationship to ResourceQuota

flowchart LR
    A[LimitRange] --> B["Defaults for containers/PVCs"]
    C[ResourceQuota] --> D[Sum bound]
    B --> E[Containers have requests]
    E --> D

The relationship:

  • LimitRange provides defaults so every container/PVC is declared.
  • ResourceQuota bounds the sum of declared values.

Without LimitRange, ResourceQuota cannot enforce boundaries on undeclared containers.

Quiz

Knowledge check · 4 questions

  1. Q1. What does LimitRange do that ResourceQuota does not?

  2. Q2. Without a LimitRange, a ResourceQuota on `requests.cpu` can be bypassed by omitting requests.

  3. Q3. Every deploy into a new namespace is rejected with a message about unspecified limits; work out what the tenant template left behind.

    `orders-staging` was created last night by copying the ResourceQuota from `orders-prod`. Every `kubectl apply` of a Deployment now produces no Pods, and the ReplicaSet events read `is forbidden: failed quota: compute: must specify limits.cpu,limits.memory,requests.cpu,requests.memory`. `kubectl get limitrange -n orders-staging` returns nothing, while `orders-prod` has one. The containers in these manifests declare no `resources` block at all.

  4. Q4. In which order do the LimitRange and ResourceQuota admission plugins see the same Pod, and why does that order matter?

Passing score: 75%. Answers are checked in this browser.

The operational discipline

LimitRange in production rests on five non-negotiable elements:

  • Apply LimitRange alongside ResourceQuota. Without one, the other is incomplete.
  • Set sensible defaults. 500m CPU, 512Mi memory is a reasonable starting point.
  • Set max constraints. Prevent one container from consuming the entire quota.
  • Set min constraints. Ensure every container declares some resources.
  • Test the constraints. Quarterly: create a Pod that exceeds max; verify rejection.

LimitRange is the declaration enforcement. ResourceQuota is the sum enforcement. Together they form a coherent system.