ResourceQuota caps a namespace; LimitRange gives every container sensible defaults.

They act at admission, before the scheduler, which creates two different-looking failures that are easy to confuse.

quota and defaults for namespace shop

kind: ResourceQuota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi
    limits.cpu: "40"
    pods: "50"
---
kind: LimitRange
spec:
  limits:
  - type: Container
    defaultRequest: {cpu: 250m, memory: 256Mi}
    default:        {cpu: 500m, memory: 512Mi}
    max:            {cpu: "2",  memory: 4Gi}

Quota exceeded

Rejected at admission. The Pod object is never created, so kubectl get pods shows nothing. Look at the error and kubectl describe resourcequota.

No node fits

Admitted, created, then Pending with a FailedScheduling event. The Pod exists and can be described.

Why LimitRange

A forgotten resources block would make a Pod BestEffort. The default request lifts it to Burstable automatically.

Quota is a policy decision (this namespace may not have more); scheduling failure is a capacity decision (no node can host this right now).

Namespaces get budgets and defaults

Per-Pod requests and limits are only half of resource governance. In a shared cluster, platform teams set namespace-level budgets with a ResourceQuota, which caps the total requests, limits, object counts and storage a namespace may use, and defaults with a LimitRange, which supplies default requests and limits for containers that omit them and can set per-container minimums and maximums.

Both are enforced by admission controllers, which is the stage before persistence. A request that would exceed the quota is rejected outright and the Pod object is never created. This is why a quota failure looks like a Pod that simply vanished, with the explanation only in the error returned to the client or in the owning ReplicaSet's events. Contrast that with a scheduling failure, where the Pod exists, shows Pending, and carries a FailedScheduling event.

Confusing the two wastes real debugging time. When a Deployment shows fewer Pods than desired and kubectl get pods lists no Pending Pods, check the ReplicaSet events and the namespace quota. When you do see Pending Pods, check node capacity, taints and affinity.

LimitRange is a quiet safety net: with a sensible defaultRequest, a developer who forgets a resources block still gets Burstable QoS rather than BestEffort. Combine both with admission policy engines (Kyverno, Gatekeeper) to require requests on every workload.