How to fix limit range exceeded in Kubernetes

KubernetesBEGINNERMEDIUMUpdated Dec 6, 2025· 139 views

LimitRange policies enforce minimum and maximum resource requests/limits per pod or container. Exceeding these limits prevents pod creation and violates namespace policy.

Quick fix

Fixes limit range exceeded

kubectl get limitrange -n <namespace>
kubectl describe limitrange -n <namespace>
  1. Identify the LimitRange that is blocking the pod
  2. Check your pod spec against LimitRange limits
  3. Adjust pod resources within LimitRange
  4. Increase LimitRange if application genuinely needs more resources
kubernetes — error
kubectl get limitrange -n <namespace>
kubectl describe limitrange -n <namespace>
limit range exceeded

What this error means

LimitRange is a namespace-level policy that defines: 1. Min/max CPU per container 2. Min/max memory per container 3. Min/max CPU per pod 4. Min/max memory per pod 5. Default request/limit values When a pod's resources exceed LimitRange boundaries, the API server rejects the pod with a validation error. This enforces resource discipline and prevents runaway resource consumption.

Typical symptoms

  • kubectl apply fails with "exceeds maximum memory"
  • Pod creation rejected with LimitRange validation error
  • Error mentions "pod exceeds max memory" or "container exceeds min cpu"
  • API server returns 403 Forbidden for pod creation
  • Events show "admission controller denied the request"
  • Deployment cannot scale due to LimitRange violations
  • HPA scaling fails when trying to create new pods

Common causes

  1. Pod requests exceed maximum limits in LimitRange
  2. Container memory request too high (> max)
  3. Container CPU request too low (< min)
  4. Pod total resource exceed aggregate limits
  5. LimitRange policy very restrictive for large applications
  6. Incorrect LimitRange configuration (typo in values)
  7. LimitRange updated without updating existing pod specs

How to fix "limit range exceeded"

1Identify the LimitRange that is blocking the pod

Check what LimitRange policies exist in the namespace:

bash
kubectl get limitrange -n <namespace>
kubectl describe limitrange -n <namespace>

Example output:

bash
Name:       cpu-memory-limit
Namespace:  default
Type       Resource         Min     Max     Request Limit   Divisible By
----       --------         ---     ---     ------- -----   -----------
Container  cpu              100m    2       -       -       -
Container  memory           128Mi   1Gi     -       -       -
Pod        cpu              200m    4       -       -       -
Pod        memory           256Mi   2Gi     -       -       -

This limits containers to 100m-2 CPU and pods to 200m-4 CPU.

2Check your pod spec against LimitRange limits

View the pod/deployment that's being rejected:

bash
kubectl apply -f pod.yaml  # This will show the error
# Error: pods "myapp" is forbidden: pod cpu limit exceeds maximum

Examine the pod spec:

bash
kubectl get pod <pod-name> -o yaml | grep -A10 resources:

Example pod spec:

yaml
spec:
  containers:
  - name: app
    image: myapp
    resources:
      requests:
        cpu: 2          # Requests 2 CPU (may exceed limit)
        memory: 1Gi     # Requests 1Gi memory
      limits:
        cpu: 4          # Limits 4 CPU (exceeds max of 2)
        memory: 2Gi     # Limits 2Gi memory

Compare against LimitRange:
- Container CPU max: 2 → limits: 4 is EXCEEDED
- Container memory max: 1Gi → limits: 2Gi is EXCEEDED
- Pod CPU max: 4 → total 4 is OK
- Pod memory max: 2Gi → total 2Gi is OK

3Adjust pod resources within LimitRange

Edit the pod/deployment to fit within limits:

bash
kubectl edit deployment <name> -n <namespace>

Reduce resource requests/limits:

yaml
spec:
  containers:
  - name: app
    resources:
      requests:
        cpu: 500m       # Within max of 2
        memory: 256Mi   # Within max of 1Gi
      limits:
        cpu: 1          # Within max of 2
        memory: 512Mi   # Within max of 1Gi

Or let the system apply defaults:

yaml
spec:
  containers:
  - name: app
    # Omit requests/limits to use LimitRange defaults

LimitRange will auto-fill defaults if not specified.

Apply and verify:

bash
kubectl apply -f deployment.yaml
kubectl get pods <pod> -o yaml | grep -A5 resources:
4Increase LimitRange if application genuinely needs more resources

If your application needs more than LimitRange allows, increase the limits:

bash
kubectl edit limitrange <name> -n <namespace>

Update the limits:

yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-memory-limit
spec:
  limits:
  - type: Container
    min:
      cpu: 100m
      memory: 128Mi
    max:
      cpu: 4          # Increased from 2
      memory: 2Gi     # Increased from 1Gi
  - type: Pod
    min:
      cpu: 200m
      memory: 256Mi
    max:
      cpu: 8          # Increased from 4
      memory: 4Gi     # Increased from 2Gi

Apply:

bash
kubectl apply -f limitrange.yaml

Then retry pod creation:

bash
kubectl apply -f pod.yaml
5Check if LimitRange applies to your namespace

Verify the LimitRange is in your pod's namespace:

bash
kubectl get limitrange -n <pod-namespace>

If no LimitRange exists in the pod's namespace, the limit should not apply.

If you're using a different namespace:

bash
kubectl get pods -n <namespace>
kubectl get limitrange -n <namespace>

LimitRange is namespace-scoped, so create/update the correct one.

For temporary testing, create a namespace without LimitRange:

bash
kubectl create namespace test
kubectl apply -f pod.yaml -n test  # Should succeed
6Remove LimitRange if not needed

If the LimitRange is too restrictive for your use case:

bash
kubectl delete limitrange <name> -n <namespace>

Warning: Without LimitRange, pods can request unlimited resources, potentially causing cluster overload.

Better alternative: Adjust LimitRange to be more flexible:

yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: permissive
spec:
  limits:
  - type: Container
    min:
      cpu: 10m        # Very permissive minimum
      memory: 32Mi    # Low memory minimum
    max:
      cpu: 64         # High maximum
      memory: 128Gi   # Very high maximum
  - type: Pod
    max:
      cpu: 256        # Cluster-wide pod limit
      memory: 256Gi

Or implement ResourceQuota instead (more flexible):

yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
spec:
  hard:
    requests.cpu: "100"
    requests.memory: "200Gi"
    limits.cpu: "200"
    limits.memory: "400Gi"
7Set appropriate defaults for LimitRange

LimitRange can auto-apply defaults if pods don't specify resources:

yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: defaults
spec:
  limits:
  - type: Container
    default:           # Applied if limits not specified
      cpu: 500m
      memory: 512Mi
    defaultRequest:    # Applied if requests not specified
      cpu: 100m
      memory: 128Mi
    max:
      cpu: 2
      memory: 1Gi

Now pods without resource specs will automatically get defaults:

bash
kubectl apply -f pod.yaml  # No resources specified
kubectl get pod <pod> -o yaml | grep -A5 resources:
# Shows: cpu: 500m, memory: 512Mi (from default)

This prevents the common pattern of uncontrolled resource usage.

8Verify LimitRange is properly applied

After fixing the pod spec, verify it's accepted:

bash
kubectl apply -f pod.yaml --dry-run=client -o yaml | grep -A5 resources:
kubectl apply -f pod.yaml
kubectl get pods <pod> -o yaml | grep -A5 resources:

The pod should now be in Running state:

bash
kubectl get pods
# NAME    READY   STATUS    RESTARTS   AGE
# myapp   1/1     Running   0          2m

Check if defaults were applied:

bash
kubectl get pod <pod> -o jsonpath='{.spec.containers[0].resources}'

Should show:

json
{"requests":{"cpu":"100m","memory":"128Mi"},"limits":{"cpu":"500m","memory":"512Mi"}}

Advanced notes

LimitRange is useful for preventing runaway resource consumption, but it should be balanced with application needs. In multi-tenant clusters, use separate LimitRanges per tenant namespace. Combine LimitRange with ResourceQuota for comprehensive resource governance. For autoscaling (HPA, VPA), ensure LimitRange doesn't prevent desired scaling. Monitor Pod QoS classes: Guaranteed (limits=requests), Burstable (requests<limits), BestEffort (no limits) are handled differently during resource pressure. Kyverno can enforce resource policies more flexibly than LimitRange. For development, create permissive LimitRanges; for production, be more restrictive. WSL2 may have cluster-wide resource limits that interact with LimitRange—test thoroughly in target environment.

Frequently asked questions

What does "limit range exceeded" mean?
LimitRange is a namespace-level policy that defines: 1. Min/max CPU per container 2. Min/max memory per container 3.
How do I fix "limit range exceeded"?
LimitRange policies enforce minimum and maximum resource requests/limits per pod or container. Exceeding these limits prevents pod creation and violates namespace policy.
What causes "limit range exceeded"?
Pod requests exceed maximum limits in LimitRange Container memory request too high (> max) Container CPU request too low (< min)
Is the "limit range exceeded" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading