Kubernetes Resource Management Areas

Kubernetes Resource Management Areas is the categorization of Kubernetes' resource management responsibilities into a small number of recurring functional domains — per-container declaration, per-node enforcement, per-namespace aggregation, and cluster-wide capacity signaling — each addressing resource concerns at a different granularity and each governed by a distinct set of API objects and mechanisms. While all of these areas ultimately revolve around the same underlying quantities (CPU, memory, storage, extended resources), they operate at different scopes and serve different operational purposes, and recognizing which area a given resource management question belongs to clarifies which tools and objects are actually relevant to answering it.

Per-Container Declaration

Requests and Limits

The foundational area: every container declares resources.requests (informing scheduling) and resources.limits (informing runtime enforcement) for CPU, memory, and any extended resources it needs — this is the area every other resource management area ultimately builds upon, since quotas, QoS classification, and eviction priority are all derived from these per-container values.

resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

Per-Node Runtime Enforcement

cgroup-Based Limit Enforcement

The kubelet, in cooperation with the container runtime, translates declared limits into Linux cgroup constraints — CPU limits become CFS quota/period settings (or cgroup v2 equivalents), memory limits become hard memory ceilings enforced by the kernel's OOM killer when exceeded.

Node-Level Eviction

When a node experiences genuine resource pressure (MemoryPressure, DiskPressure, PIDPressure conditions), the kubelet's eviction manager terminates Pods according to QoS class and usage-relative-to-request ranking, reclaiming resources at the node level rather than waiting for cluster-wide intervention.

kubectl describe node node-worker-05 | grep -A 5 "Conditions"

Per-Namespace Aggregation

ResourceQuota

Bounds the total resource consumption (and, optionally, object counts) permitted across all Pods within a namespace, preventing any single namespace from consuming more than its allotted share of a shared cluster's total capacity.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-team-quota
spec:
  hard:
    requests.cpu: "20"
    requests.memory: "40Gi"
    limits.cpu: "40"
    limits.memory: "80Gi"

LimitRange

Establishes default requests/limits for containers that do not specify their own within a namespace, and can bound the minimum/maximum values individual containers are allowed to declare — this area exists specifically to guard against Pods with missing or extreme resource declarations slipping through without any resource accounting at all.

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

Quality of Service Classification

The QoS Layer Connecting Declaration to Eviction

Guaranteed, Burstable, and BestEffort QoS classes are derived automatically from the relationship between a Pod's requests and limits, and this classification is the area that connects per-container declaration (area one) to per-node eviction behavior (area two) — QoS is not a separately configured area so much as a computed property spanning the two.

Cluster-Wide Capacity Signaling

Metrics and Autoscaling Inputs

While cluster autoscaling itself lies outside Kubernetes' core resource management scope, the resource usage and request data produced by the areas above (via the Metrics API, kubectl top, and the Vertical/Horizontal Pod Autoscalers) feed directly into cluster-level capacity decisions — this area is the bridge between in-cluster resource management data and external capacity-provisioning systems that consume it.

kubectl top nodes
kubectl top pods --all-namespaces

Extended and Custom Resources

Device Plugins and Custom Resource Types

Beyond CPU and memory, the extended resource area covers hardware resources (GPUs, specialized NICs) advertised to the cluster via device plugins and consumed through the same resources.requests/limits syntax, with the scheduler treating them as additional dimensions in its fit calculation alongside ordinary CPU and memory.

resources:
  limits:
    nvidia.com/gpu: 1

Example Tying the Areas Together

apiVersion: v1
kind: Namespace
metadata:
  name: codartium-team
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-quota
  namespace: codartium-team
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
---
apiVersion: v1
kind: Pod
metadata:
  name: codartium-areas-example
  namespace: codartium-team
spec:
  containers:
    - name: app
      image: codartium/app:latest
      resources:
        requests:
          cpu: "250m"
          memory: "256Mi"
        limits:
          cpu: "250m"
          memory: "256Mi"