ResourceQuota and LimitRange
A ResourceQuota caps what a namespace may consume in total, and it has a side effect nobody expects the first time: once you quota a compute resource, every Pod must declare it, and `kubectl run` stops working. A LimitRange is the other half - it injects defaults so the same command succeeds again. Both rejections and the fix are captured here.
Configuration and Security Guide 27 of 44 Intermediate
- Kubernetes1.36.4
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 15 min
- Reviewed23 August 2026
Written against the versions above. The quota's `status.used` is maintained by a controller and is the number admission checks against, so a rejected Pod does not consume any of it. A LimitRange's `default` becomes the container's LIMIT and `defaultRequest` becomes its REQUEST - and if you set only `default`, the request is set equal to it, which quietly makes every Pod Guaranteed.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
Before you start
- A cluster and kubectl, with permission to create ResourceQuota and LimitRange objects.
- The session creates namespace
ckad-quota, a compute quota, and then a LimitRange, triggering two rejections along the way.
-
A quota on the namespace
-
The Pod that is now refused
-
With resources, it is accepted
-
A LimitRange fills them in
-
And the maximum it enforces