KubernetesCIX · LimitRangeLimitRange
LimitRange overview — defaults and constraints per container and Pod
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
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
Q1. What does LimitRange do that ResourceQuota does not?
Q2. Without a LimitRange, a ResourceQuota on `requests.cpu` can be bypassed by omitting requests.
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.
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.