CertGrid CertGrid
Hands-on Lab·Certified Kubernetes Application Developer

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

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.

One namespace with a quota and a limit range. Admission happens in the API server, so node placement is irrelevant here.
Server NameIP AddressOSRolesCPURAMHDD
CKA1001192.168.0.175Ubuntu 26.04 LTSControl Plane Node2 Core4 GB50 GB
CKA1001-NODE01192.168.0.176Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE02192.168.0.177Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB
CKA1001-NODE03192.168.0.178Ubuntu 26.04 LTSWorker Node2 Core4 GB50 GB

Before you start

  1. A quota on the namespace

  2. The Pod that is now refused

  3. With resources, it is accepted

  4. A LimitRange fills them in

  5. And the maximum it enforces

Official sources