Kubernetes Resource Governance Admission

Kubernetes Resource Governance Admission is the set of admission plugins and policies responsible for controlling how compute resources — CPU, memory, ephemeral storage, and object counts — are requested, defaulted, and capped as workloads are created within a cluster. Built around the LimitRanger and ResourceQuota plugins primarily, this admission layer ensures that resource consumption stays predictable and fairly distributed across the teams and namespaces sharing a cluster's finite capacity.

LimitRanger: Defaults and Per-Object Bounds

Setting Sensible Defaults

LimitRanger enforces a LimitRange object's configuration, applying default resource requests and limits to any container that omits them, ensuring that no workload is scheduled with entirely unbounded or unspecified resource consumption simply because its author forgot to specify limits.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: payments
spec:
  limits:
  - default:
      cpu: "500m"
      memory: "512Mi"
    defaultRequest:
      cpu: "250m"
      memory: "256Mi"
    type: Container

Enforcing Minimum and Maximum Bounds

Beyond defaults, a LimitRange can specify min and max values per container, rejecting any pod that requests resources outside these bounds — preventing both a container so small it risks constant throttling and a container so large it could monopolize a node's capacity.

spec:
  limits:
  - min:
      cpu: "50m"
    max:
      cpu: "4"
    type: Container

Ratio Enforcement

LimitRange can also enforce a maximum limit-to-request ratio, ensuring a container's burst limit does not vastly exceed its baseline request in a way that would make scheduling decisions based on requests unreliable predictors of actual node consumption.

ResourceQuota: Aggregate Namespace Limits

Capping Total Consumption

ResourceQuota enforces cluster-wide or namespace-wide aggregate limits on total CPU, memory, storage, and object counts (number of pods, services, secrets, and so on), rejecting any request that would push the namespace's cumulative usage beyond its configured quota.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: payments-quota
  namespace: payments
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"
    pods: "50"

Requiring Explicit Resource Specifications

When a ResourceQuota covers requests.cpu or requests.memory, any pod submitted without explicit resource requests for that dimension is rejected outright, rather than silently defaulted — making ResourceQuota and LimitRanger complementary: LimitRanger can supply the missing defaults ResourceQuota would otherwise require to be explicit.

Object Count Quotas

Beyond compute resources, ResourceQuota can cap the number of specific object types a namespace may contain, which is useful for preventing runaway automation from creating an unbounded number of Jobs, Secrets, or PersistentVolumeClaims within a single namespace.

Interaction Between the Two Plugins

Ordering Matters

LimitRanger applies defaults before ResourceQuota evaluates the resulting object against quota limits, meaning a pod that would otherwise be rejected by ResourceQuota for missing an explicit CPU request can be admitted if LimitRanger first supplies a default that satisfies the quota's requirement.

Designing Them Together

Effective resource governance sets LimitRange defaults that are generous enough for typical workloads while leaving ResourceQuota as the backstop against aggregate over-consumption, rather than relying on either mechanism alone to fully express an organization's resource governance intent.

Operational Considerations

Monitoring Quota Utilization

Tracking how close each namespace's actual usage sits to its configured quota — rather than only reacting when a deployment is rejected for exceeding it — allows capacity planning conversations to happen proactively instead of as an emergency response to a blocked deployment.

kubectl describe resourcequota payments-quota -n payments

Adjusting Quotas as Teams Grow

Because quota values represent a point-in-time capacity allocation decision, periodically revisiting them alongside actual team growth and workload evolution prevents a namespace's quota from becoming either an artificial ceiling on legitimate growth or a stale allowance far larger than the namespace's current workloads actually require.