✦ For everyone, free.

Practical knowledge for real and everyday life

Home

Kubernetes Resource Management

Kubernetes Resource Management ensures efficient use of cluster resources through scheduling, allocation, and monitoring across containerized workloads.

Kubernetes Resource Management is the set of mechanisms by which the platform accounts for, allocates, enforces, and constrains the compute resources, CPU, memory, ephemeral storage, and extended resources such as GPUs, consumed by workloads across a cluster. It spans decisions made at multiple levels: individual containers declare what they need, the scheduler allocates capacity accordingly, the kubelet enforces limits at runtime, and cluster-wide policies constrain how much any given namespace or object may consume in aggregate.

Requests and Limits

Requests

A resource request specifies the minimum amount of a resource a container is expected to need. The scheduler uses the sum of a Pod's container requests to determine whether a candidate node has sufficient allocatable capacity, guaranteeing that a Pod is only placed on a node that can satisfy its stated requirements.

Limits

A resource limit specifies the maximum amount of a resource a container is permitted to consume. The kubelet, working through the underlying operating system's cgroup mechanism, enforces this ceiling at runtime: exceeding a memory limit results in the container being terminated (OOMKilled), while exceeding a CPU limit results in throttling rather than termination, since CPU is a compressible resource.

resources:
  requests:
    cpu: "200m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"
request ≤ actual usage ≤ limit

Quality of Service Classes

Kubernetes assigns each Pod one of three Quality of Service (QoS) classes based on how its containers configure requests and limits, and uses this classification to prioritize eviction decisions under resource pressure.

  • Guaranteed: Every container specifies both requests and limits, and they are equal for every resource. These Pods are evicted last.
  • Burstable: At least one container specifies a request, but requests and limits are not equal across all containers and resources. These Pods are evicted after BestEffort but before Guaranteed.
  • BestEffort: No container specifies any request or limit. These Pods are evicted first under resource pressure.
kubectl get pod codartium-app-abc123 -o jsonpath='{.status.qosClass}'

Namespace-Level Resource Governance

ResourceQuota

A ResourceQuota object constrains the aggregate resource consumption, and, optionally, the count of objects of a given type, within a namespace, preventing any single namespace from monopolizing cluster capacity.

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

LimitRange

A LimitRange sets default, minimum, and maximum resource values applied to individual containers or Pods within a namespace, ensuring that workloads omitting explicit requests or limits still receive sensible defaults rather than being scheduled as unconstrained BestEffort Pods.

apiVersion: v1
kind: LimitRange
metadata:
  name: codartium-defaults
  namespace: codartium-team
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "100m"
        memory: "128Mi"
      type: Container

Node Capacity and Allocatable Resources

Capacity vs. Allocatable

A node's total capacity includes resources reserved for the operating system and Kubernetes system daemons; the allocatable value, which is what the scheduler actually uses, subtracts these reservations from capacity, ensuring Pods are never scheduled in a way that starves the node's own critical processes.

allocatable = capacity - kube-reserved - system-reserved - eviction-threshold

Node Pressure Eviction

When a node's available resources fall below configured eviction thresholds, memory, disk, or PID pressure, the kubelet begins evicting Pods to reclaim capacity, selecting victims according to QoS class first and resource usage relative to requests second.

Autoscaling Resource Allocation

Horizontal Pod Autoscaler

The Horizontal Pod Autoscaler adjusts the number of replicas of a workload in response to observed metrics, most commonly average CPU or memory utilization relative to requests, scaling out under load and back in as demand subsides.

Vertical Pod Autoscaler

The Vertical Pod Autoscaler observes actual resource usage over time and recommends, or automatically applies, adjusted request and limit values for a workload's containers, addressing cases where the correct sizing is not known in advance or changes over the application's lifetime.

Cluster Autoscaler

The Cluster Autoscaler operates at the node level, adding nodes when Pods cannot be scheduled due to insufficient cluster capacity and removing underutilized nodes, keeping overall cluster resource supply aligned with aggregate demand from all Pods.

kubectl top nodes
kubectl top pods --containers
kubectl describe resourcequota codartium-team-quota -n codartium-team

Extended Resources

Beyond CPU and memory, Kubernetes supports scheduling against extended resources, such as GPUs or specialized hardware, advertised by device plugins running on individual nodes, allowing the same request-and-limit model to govern access to hardware resources that are not natively understood by the core scheduler.

Related content