ResourceQuota and LimitRange

Configuration and Security / Guide 27 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 15 min

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.

This guide includes

Use this when the simplest possible kubectl run is refused in one namespace and works everywhere else. This matters because a ResourceQuota has a side effect people do not expect - once one exists, every Pod must declare resources or be rejected outright.

• putting a ResourceQuota on a namespace and reading the four caps it sets
• watching a plain kubectl run be refused because it declares no resources
• supplying all four fields, and seeing the quota's used figure move
• adding a LimitRange so the original command works again through filled-in defaults
• seeing the maximum that a LimitRange also enforces

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.

1. 1

   A quota on the namespace

2. 2

   The Pod that is now refused

3. 3

   With resources, it is accepted

4. 4

   A LimitRange fills them in

5. 5

   And the maximum it enforces

Official sources

• Resource Quotas
• Limit Ranges
• Configure Default Memory Requests and Limits