MeteorOps | DevOps Dictionary | Kubernetes LimitRange

Kubernetes LimitRange

Kubernetes LimitRange is a namespace-scoped policy that sets default, minimum, and maximum CPU, memory, or storage values for pods, containers, and persistent volume claims at admission time. In practical terms, it gives platform teams guardrails so workloads in a namespace do not run without resource settings or request an unreasonable amount of cluster capacity.

What a Kubernetes LimitRange does

A LimitRange controls resource settings for objects created inside one namespace. It can:

Set default CPU and memory requests for containers that do not define them.
Set default CPU and memory limits for containers that do not define them.
Reject pods or containers that request less than a minimum value.
Reject pods or containers that request more than a maximum value.
Limit the ratio between requests and limits, such as preventing a container from requesting 100m CPU while setting a 4 CPU limit.
Set minimum and maximum storage requests for PersistentVolumeClaims.

This is useful in shared clusters where teams deploy many services and not every manifest, Helm chart, or generated workload has consistent resource settings.

How it works

LimitRange is enforced by the Kubernetes admission process before the API server stores a new or updated object. If the object is missing values, Kubernetes can add defaults from the LimitRange. If the object violates a rule, Kubernetes rejects it.

A LimitRange does not continuously monitor running pods. It does not resize existing pods. If you change a LimitRange, existing pods keep their current resource settings until they are recreated or updated.

Resource enforcement still happens through normal Kubernetes mechanisms:

CPU requests affect scheduling. The scheduler uses them to decide which node can fit the pod.
CPU limits can cause throttling when a container tries to use more CPU than allowed.
Memory requests affect scheduling.
Memory limits can cause the container to be killed with an OOMKilled event if it exceeds the limit.

Key fields

A LimitRange usually contains one or more entries under spec.limits. Common fields include:

type: The object type the rule applies to, such as Container, Pod, or PersistentVolumeClaim.
default: The default limit applied when a container does not specify one.
defaultRequest: The default request applied when a container does not specify one.
min: The minimum allowed request or limit.
max: The maximum allowed request or limit.
maxLimitRequestRatio: The maximum allowed ratio between a limit and a request.

Example

This LimitRange sets default CPU and memory values for containers in the dev namespace and rejects containers outside the configured range:

apiVersion: v1
kind: LimitRange
metadata:
  name: compute-limits
  namespace: dev
spec:
  limits:
    - type: Container
      default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      min:
        cpu: "50m"
        memory: "64Mi"
      max:
        cpu: "2"
        memory: "2Gi"

With this policy, a container that does not define resources gets a CPU request of 100m, a memory request of 128Mi, a CPU limit of 500m, and a memory limit of 512Mi. A container that asks for 8Gi of memory would be rejected because it exceeds the configured maximum.

Common use cases

Shared development namespaces: Apply safe defaults so ad hoc services do not run as BestEffort pods.
Multi-team clusters: Prevent one team from creating pods with very large per-container limits in a shared namespace.
CI workloads: Cap build jobs so a single pipeline cannot consume too much CPU or memory.
Stateful workloads: Set minimum and maximum PersistentVolumeClaim sizes to avoid tiny unusable volumes or oversized claims.
Platform standards: Keep Helm charts, raw manifests, and generated workloads aligned with your cluster resource model.

For example, if a team runs Apache Airflow on AWS EKS, they may use a LimitRange to give scheduler, webserver, and worker pods reasonable defaults while still allowing explicit overrides for heavier tasks.

LimitRange vs ResourceQuota

LimitRange and ResourceQuota are often used together, but they solve different problems.

LimitRange controls resource values per object, such as per container, per pod, or per PersistentVolumeClaim.
ResourceQuota controls total resource usage across a namespace, such as total requested CPU, total memory limits, pod count, or PVC count.

A practical setup might use a LimitRange to say “no container can request more than 2 CPU,” then use a ResourceQuota to say “this namespace can request no more than 20 CPU in total.”

Benefits

More predictable scheduling: Default requests help the scheduler place pods based on expected resource use.
Fewer unbounded workloads: Default limits reduce the chance that a container consumes too much CPU or memory.
Better namespace isolation: Teams can share clusters with clearer per-workload boundaries.
Cleaner platform policy: You can define baseline rules once per namespace instead of relying on every developer to remember them.

If you manage policies as code, you can create LimitRange objects the same way you manage Kubernetes resources using Terraform, Helm, Kustomize, or GitOps workflows.

Tradeoffs and limitations

Bad defaults can hurt reliability: A memory limit that is too low can cause repeated OOMKilled events. A CPU limit that is too low can cause throttling.
It only applies at admission time: Existing pods are not updated when you change the LimitRange.
It is namespace-scoped: You need to apply it separately to each namespace that needs the policy.
It does not replace capacity planning: LimitRange sets boundaries, but it does not tell you the correct values for each service.
Multiple LimitRanges can be confusing: Avoid overlapping defaults in the same namespace because it can be hard to predict which default will apply.

Related Kubernetes concepts

Requests and limits: The resource values that LimitRange defaults or validates.
ResourceQuota: A namespace-level cap on total resource consumption.
Quality of Service classes: Kubernetes classifies pods as Guaranteed, Burstable, or BestEffort based on requests and limits.
Vertical Pod Autoscaler: Recommends or updates pod resource requests based on observed usage.
Admission controllers: Kubernetes components that validate or mutate objects before they are persisted.

LimitRange also deserves attention during cluster maintenance. When you update Kubernetes versions, Helm charts, or platform defaults, confirm that new workloads still pass admission. Add LimitRange checks to your Kubernetes upgrade checklist so deployments do not fail unexpectedly after a policy change.

Simple real-world example

A startup runs a shared dev namespace for 20 engineers. Some services define requests and limits, but others come from quick test manifests with no resource settings. Without a LimitRange, those pods may run as BestEffort, compete poorly under node pressure, and make scheduling less predictable.

The platform team adds a LimitRange with a 100m CPU request, 128Mi memory request, 500m CPU limit, and 512Mi memory limit. Most small services run without extra configuration. Larger services can still set explicit values, but anything above the namespace maximum is rejected before it reaches the cluster.

The result is simple: developers get useful defaults, platform teams get safer boundaries, and the cluster behaves more predictably under load.

DevOps Dictionary