Skip to main content
Back to Library
mastering ckad certified kubernetes application developer

Resource Quotas and LimitRanges

2 min read Chapter 52 of 87
Summary

Introduces ResourceQuotas as the mechanism for capping total...

Introduces ResourceQuotas as the mechanism for capping total resource consumption and object counts per namespace, and LimitRanges as the mechanism for setting default, minimum, and maximum resource constraints per container. Previews Pod Disruption Budgets for availability during voluntary disruptions.

Resource Quotas and LimitRanges

Multi-tenant clusters face a fundamental tension. Teams share the same infrastructure, and without guardrails, one team’s runaway Deployment can starve everyone else. A memory leak in a staging namespace shouldn’t bring down production workloads. A developer experimenting with 50 replicas shouldn’t exhaust the cluster’s CPU allocation.

Kubernetes addresses this with two complementary mechanisms: ResourceQuotas and LimitRanges.

ResourceQuotas set a hard ceiling on the total resources a namespace can consume. If a quota limits a namespace to 4 CPU cores and 8 GiB of memory, no combination of Pods in that namespace can exceed those totals. Quotas also cap object counts — the number of Pods, Services, ConfigMaps, Secrets, and PersistentVolumeClaims in a namespace.

LimitRanges operate at the individual container level. While a ResourceQuota constrains the namespace total, a LimitRange constrains each container: if a Pod doesn’t specify resource requests and limits, the LimitRange injects defaults. If a Pod requests more than the maximum or less than the minimum, the API server rejects it. This prevents both resource hogging (one container requesting 32 GiB) and underprovisioning (one container requesting 1m CPU and hitting OOM within seconds).

Together, these mechanisms create a layered resource governance model. The LimitRange ensures every container plays within bounds; the ResourceQuota ensures the namespace as a whole does not overconsume.

A third mechanism — Pod Disruption Budgets — addresses a different concern: availability during voluntary disruptions like node drains, cluster upgrades, or kubectl-initiated deletions. While not strictly a resource quota, it complements the governance story by guaranteeing a minimum number of Pods remain available at all times.

What This Chapter Covers

The following sections provide:

  • Namespace Resource Quotas: Defining compute and object count quotas, the enforcement behavior that requires all Pods to specify resource requests/limits, and inspection commands.

  • LimitRange Defaults and Pod Disruption Budgets: Setting default, min, max, and ratio constraints on container resources, plus PDB configuration for maintaining application availability during disruptions. Ends with exercises covering Chapters 16–18.

These topics appear in the CKAD exam under resource management and namespace governance. Tasks may ask you to create a ResourceQuota, observe what happens when a Pod violates it, or create a LimitRange that applies default resource values.