Validating Resource Requests with Limit Ranges

Learners will define LimitRange objects to enforce minimum and maximum resource constraints on pods and containers within specific namespaces.

In this lesson, you will learn how to enforce resource governance within a namespace by defining LimitRange objects to automatically validate and constrain Pod resource requests.

The Problem: Resource Unpredictability

In a shared Kubernetes cluster, developers might accidentally deploy Pods without defining resource requests or limits. This leads to "noisy neighbor" scenarios where one container consumes excessive CPU or memory, potentially starving other critical workloads. While ResourceQuotas control the total aggregate consumption of a namespace, LimitRange acts as the gatekeeper for individual units of work.

How LimitRanges Work

A LimitRange object is a policy defined at the namespace level. When a Pod is submitted to the API server, the Kubernetes admission controller intercepts the request and compares the Pod's resource configuration against the LimitRange policy. If the Pod violates these constraints—such as requesting too little CPU or exceeding a maximum memory limit—the Pod is rejected immediately.

Consider this example configuration:

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-cpu-limit-range
spec:
  limits:
  - type: Container
    min:
      cpu: "100m"
      memory: "64Mi"
    max:
      cpu: "1"
      memory: "1Gi"
    default:
      cpu: "500m"
      memory: "256Mi"

In this setup:

Min/Max: Any container requesting less than 100m CPU or more than 1 CPU will be rejected.
Defaults: If a developer omits a request or limit in their Pod specification, the default values (500m CPU/256Mi RAM) are automatically injected into the container manifest.

This mechanism ensures that every Pod running in your namespace adheres to the "Goldilocks" zone—neither too small to cause scheduling inefficiency nor too large to cause cluster-wide instability. It removes the guesswork for developers while maintaining operational sanity for cluster administrators. By validating these constraints at the API level, you catch misconfigurations long before they cause runtime performance degradation.

Key Takeaway: LimitRanges provide a foundational layer of governance by enforcing minimum and maximum resource constraints and applying default values to containers at the time of Pod creation.