☸️ Kubernetes Error Guide: 'minimum cpu usage per Container' LimitRange Rejection

Exact Error Message

Error from server (Forbidden): error when creating "pod.yaml": pods "api-7d9f" is forbidden:
[minimum cpu usage per Container is 100m, but request is 50m,
maximum memory usage per Container is 512Mi, but limit is 1Gi]

You may also see it surface from a Deployment as a failed ReplicaSet event: Error creating: pods "..." is forbidden: minimum cpu usage per Container is 100m, but request is 50m.

Overview

A LimitRange is a namespace-scoped policy object that constrains the CPU and memory a Pod or Container may request or limit. When you create a workload whose resources.requests or resources.limits fall outside the min/max window the LimitRange defines, the admission controller rejects the object with Forbidden before it is ever scheduled.

This is a policy rejection, not a scheduling or capacity failure. Nothing is broken on the node. The API server refused the object because its resource numbers violate a rule an administrator set for the namespace. The message always names the exact dimension (cpu/memory), the boundary (minimum/maximum), the policy value, and your offending value.

Symptoms

• kubectl apply or kubectl create returns Forbidden immediately with a minimum/maximum ... per Container message.
• A Deployment or StatefulSet stays at zero ready replicas and its events show FailedCreate on the ReplicaSet.
• kubectl get pods shows no Pod at all for the workload — it never entered Pending.
• The same manifest applies cleanly in a different namespace that has no LimitRange.

Common Root Causes

1. Request below the enforced minimum

The LimitRange sets a floor (min) and your container requests less. Requesting 50m CPU where the floor is 100m is the classic case.

2. Limit above the enforced maximum

The LimitRange sets a ceiling (max) and your container’s limit exceeds it, for example a 1Gi memory limit against a 512Mi max.

3. No requests or limits set at all

If the LimitRange has a min but the container omits requests, the default may still fall below the floor, or a maxLimitRequestRatio may be violated once defaults are injected.

4. Ratio constraint violated

maxLimitRequestRatio caps how far a limit may exceed its request. A 100m request with a 1000m limit fails a ratio of 4.

Diagnostic Workflow

Step 1: Read the offending numbers from the error

The message is self-describing. Note the dimension, whether it is minimum or maximum, and both values.

Step 2: Inspect the LimitRange in the namespace

kubectl get limitrange -n production
kubectl describe limitrange -n production

This prints the Min, Max, Default, Default Request, and Max Limit/Request Ratio columns per resource type.

Step 3: Confirm your workload’s current numbers

kubectl get deploy api -n production -o jsonpath='{.spec.template.spec.containers[*].resources}'

Step 4: Reconcile the two

Compare each container’s requests/limits against the LimitRange window. Every value must sit inside [min, max] and respect any ratio.

Step-by-Step Resolution

1. Identify the exact boundary you crossed from the error text, for example minimum cpu usage per Container is 100m, but request is 50m.

2. Describe the LimitRange to see the full policy, not just the one rule that fired:

kubectl describe limitrange cpu-mem-limits -n production

3. Edit the workload so every container falls inside the window. For the CPU-floor case, raise the request to meet or exceed the minimum:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

4. Re-apply and confirm the object is accepted:

kubectl apply -f deployment.yaml
kubectl get pods -n production -w

5. If the policy itself is wrong for your workload, and you own the namespace policy, edit the LimitRange instead of the app:

kubectl edit limitrange cpu-mem-limits -n production

6. Verify no lingering rejections remain in the ReplicaSet events:

kubectl describe rs -n production -l app=api | grep -A3 Events

For generating compliant resource blocks quickly across many manifests, the DevOps AI prompt library has ready-made prompts.

Prevention

• Treat LimitRange values as contract: document the namespace min/max/ratio so app teams set requests correctly the first time.
• Set explicit requests and limits on every container rather than relying on injected defaults that may not satisfy maxLimitRequestRatio.
• Validate manifests in CI against the target namespace’s LimitRange using kubectl apply --dry-run=server, which runs admission checks without creating objects.
• Keep a maxLimitRequestRatio modest but not so tight that reasonable burst limits are rejected.
• When rolling out a new LimitRange, audit existing workloads first — tightening a floor can break running Deployments on their next rollout.

Related Errors

• Error creating: pods "..." is forbidden: exceeded quota — a ResourceQuota, not a LimitRange, capping namespace totals.
• 0/3 nodes are available: Insufficient cpu — a genuine scheduling/capacity failure, unlike this policy rejection.
• must specify limits.cpu — a LimitRange with a required limit that your container omitted.
• maximum memory usage per Container is 512Mi, but limit is 1Gi — the ceiling variant of this same error.

Frequently Asked Questions

Why does my Pod never appear in kubectl get pods? Because the LimitRange rejection happens at admission time, before the Pod object is persisted. There is nothing to schedule, so no Pending Pod exists — only a FailedCreate event on the controller.

How do I see the exact limits the namespace enforces? Run kubectl describe limitrange -n <namespace>. It lists the Min, Max, Default, Default Request, and Max Limit/Request Ratio for CPU and memory.

Can I bypass the LimitRange for one workload? No. LimitRanges apply to every Pod created in the namespace. Either bring the workload into compliance, adjust the LimitRange, or deploy into a namespace without that policy.

Does setting only limits and no requests fix it? Not necessarily. Kubernetes copies limits into requests when requests are absent, so the copied request must still satisfy the min. A ratio constraint can still fire once defaults are applied.

For more container-policy and resource-management fixes, see the Kubernetes & Helm guides.