Kubernetes LimitRange Management

Kubernetes LimitRange Management is the detailed configuration and operational practice surrounding LimitRange objects, which establish per-object constraints — minimum, maximum, default, and default-request values, along with limit-to-request ratio bounds — applied automatically to Container, Pod, and PersistentVolumeClaim objects within a namespace as they are created. Where ResourceQuota governs aggregate consumption across an entire namespace, LimitRange governs the shape of individual objects within it, and unlike quota, it can actively modify an incoming object (supplying missing defaults) rather than only accepting or rejecting it outright.

A namespace can have multiple LimitRange objects simultaneously, each targeting different object types or providing overlapping constraints, and understanding how multiple LimitRange rules interact is necessary for predicting the actual defaults and bounds a given container will receive.

LimitRange Types

type: Container

The most commonly used type, applying min, max, default, defaultRequest, and maxLimitRequestRatio to individual containers within any Pod created in the namespace.

apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-container-limits
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "250m"
        memory: "256Mi"
      max:
        cpu: "2"
        memory: "2Gi"
      min:
        cpu: "50m"
        memory: "64Mi"
      maxLimitRequestRatio:
        cpu: "4"
        memory: "2"

type: Pod

Bounds the aggregate request/limit across all containers within a single Pod (summed, following the same combination logic as the Pod-level resource calculation), useful for capping how large any single Pod can be regardless of how many containers it contains.

spec:
  limits:
    - type: Pod
      max:
        cpu: "4"
        memory: "4Gi"

type: PersistentVolumeClaim

Bounds the minimum and maximum storage size an individual PersistentVolumeClaim may request within the namespace, independent of the aggregate ResourceQuota storage ceiling.

spec:
  limits:
    - type: PersistentVolumeClaim
      min:
        storage: "1Gi"
      max:
        storage: "100Gi"

Field Semantics

default and defaultRequest Apply Only When Unset

default and defaultRequest are applied only to containers that do not specify their own values for the corresponding resource — an explicitly set value on the container is never overridden by a LimitRange default, which only fills genuine gaps.

min and max Are Hard Validation Bounds

Unlike defaults, min and max are enforced as strict validation constraints — a container specifying a request or limit outside these bounds is rejected outright at admission time, regardless of whether the value was explicit or would have otherwise been filled by a default.

maxLimitRequestRatio Caps Burst Headroom

maxLimitRequestRatio bounds how large a container's limit may be relative to its request — a ratio of 4 for CPU means a container's limit cannot exceed four times its request, preventing an excessively generous burst allowance that could undermine capacity planning built around request-based quota accounting.

Multiple LimitRange Objects in One Namespace

Combining Constraints Across Objects

If multiple LimitRange objects targeting the same type exist in a namespace, their constraints are combined — the effective min becomes the highest minimum across all applicable LimitRange objects, and the effective max becomes the lowest maximum, since every applicable LimitRange's bounds must simultaneously be satisfied.

Avoiding Contradictory Configurations

Because combining multiple LimitRange objects can produce an empty valid range (a min from one object exceeding the max from another), namespaces intending to use multiple LimitRange objects should verify the combined effective bounds remain satisfiable, typically by testing with a representative Pod manifest before relying on the configuration in production.

kubectl apply --dry-run=server -f test-pod.yaml

LimitRange and ResourceQuota Working Together

Why Both Are Typically Deployed Together

A LimitRange alone does not prevent a namespace's aggregate consumption from growing unbounded (many individually-compliant containers can still collectively exceed available cluster capacity); a ResourceQuota alone does not prevent an individual container from being pathologically over- or under-sized. Deploying both together addresses both the per-object and aggregate governance concerns simultaneously.

kubectl get limitrange -n codartium-team
kubectl describe limitrange codartium-container-limits -n codartium-team

Example

apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-limitrange-example
  namespace: codartium-team
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "250m"
        memory: "256Mi"
      max:
        cpu: "2"
        memory: "2Gi"
      min:
        cpu: "50m"
        memory: "64Mi"
    - type: PersistentVolumeClaim
      min:
        storage: "1Gi"
      max:
        storage: "50Gi"