Kubernetes Resource Reliability Basics

Kubernetes Resource Reliability Basics is the cluster- and namespace-wide practice of governing resource consumption so that one workload's excessive usage cannot exhaust shared capacity and degrade every other workload's reliability, covering resource quotas, limit ranges, node-level reserved capacity, and the kubelet's eviction thresholds that protect node stability under memory pressure.

Resource Quotas as Namespace-Level Guardrails

Bounding Total Consumption Per Namespace

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

A ResourceQuota caps the aggregate resource requests, limits, and object counts a namespace may consume, preventing a single team's namespace from unilaterally exhausting cluster-wide capacity in a way that starves unrelated workloads in other namespaces, a foundational multi-tenancy reliability guardrail rather than a per-workload one.

LimitRange for Per-Object Defaults and Bounds

Enforcing Sane Defaults Automatically

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-a
spec:
  limits:
    - type: Container
      default: { cpu: 500m, memory: 512Mi }
      defaultRequest: { cpu: 100m, memory: 128Mi }
      max: { cpu: 2, memory: 2Gi }
      min: { cpu: 50m, memory: 64Mi }

A LimitRange automatically injects default requests and limits onto any container that omits them, converting what would otherwise be an unintentional BestEffort (and therefore high eviction-priority) pod into an appropriately resourced Burstable one, while also enforcing minimum and maximum bounds that catch obviously misconfigured requests before they consume disproportionate scheduling capacity or fail to reserve enough to run reliably at all.

Node-Level Reserved Capacity

kube-reserved and system-reserved

kubelet --kube-reserved=cpu=200m,memory=512Mi --system-reserved=cpu=200m,memory=512Mi

Reserving a portion of each node's capacity for the kubelet, container runtime, and operating system itself, separate from what is allocatable to pods, prevents pod scheduling from consuming resources the node's own critical system processes need to keep functioning, since a node whose system processes are starved of resources becomes unreliable for every pod running on it, not just the workload that caused the contention.

Kubelet Eviction Thresholds

Soft and Hard Eviction

kubelet --eviction-hard=memory.available<100Mi,nodefs.available<10%
kubelet --eviction-soft=memory.available<300Mi
kubelet --eviction-soft-grace-period=memory.available=1m30s

Hard eviction thresholds trigger immediate pod eviction once crossed, protecting node stability without any grace period; soft eviction thresholds allow a configurable grace period before evicting, giving transient resource pressure a chance to resolve on its own before disruptive action is taken, and both mechanisms exist specifically to prevent a node from becoming so resource-starved that the kubelet itself, and every pod on that node, becomes unresponsive.

Eviction Order Under Pressure

Under memory pressure, the kubelet evicts pods in order of how far they exceed their requests relative to their QoS class, meaning the QoS classification discussed under deployment reliability basics directly determines eviction order here as well, BestEffort first, then Burstable pods exceeding requests, with Guaranteed pods evicted only in the most extreme circumstances.

Avoiding Cascading Resource Exhaustion

The Risk of Under-Reserved Clusters

A cluster running consistently near full capacity, with resource quotas set loosely enough that aggregate requests approach total allocatable capacity, has little headroom to absorb a node failure's displaced pods, a traffic spike, or a runaway workload, meaning resource governance is not merely a fairness mechanism between tenants but a direct input to the cluster's overall capacity to recover from any of the failure scenarios covered elsewhere in this knowledge area.

Priority-Based Preemption Under Quota Pressure

Ensuring Critical Workloads Remain Schedulable

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000

Even within a namespace's quota, priority classes determine which workloads can preempt others for scheduling capacity when contention occurs, meaning resource governance and priority configuration must be considered together, since a namespace's quota alone does not guarantee that its most critical workloads specifically, rather than merely some subset, retain scheduling priority under pressure.

Relationship to Deployment Reliability Basics and the Reliability Model

Resource reliability basics operates one layer above the individual-workload QoS and sizing decisions covered under deployment reliability basics, providing the namespace- and node-level governance that keeps any single workload's resource consumption from undermining the reliability of every other workload sharing the same cluster, a direct extension of the reliability model's principle that redundancy and fast recovery are only effective if the underlying capacity to schedule replacement or additional replicas actually remains available when needed.