How to fix limit range exceeded in Kubernetes | DevErrors

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"}}

How to fix limit range exceeded in Kubernetes

What this error means

Typical symptoms

Common causes

How to fix "limit range exceeded"

Advanced notes

Related errors

Official resources & further reading