Skip to main content
Beyond big-picture platform architecture, this lesson covers something that affects every Pod you deploy: how to tell Kubernetes what your workload actually needs. Here you’ll learn the difference between resource requests and limits, how to configure them correctly, how Kubernetes assigns QoS classes, and the eviction order under memory pressure. You’ll also get a practical right-sizing workflow to reduce cost and improve reliability.
The image lists four learning objectives focused on resource management in Kubernetes, such as differentiating between resource requests and limits, configuring them correctly, understanding Quality of Service (QoS) classes, and describing eviction priority under memory pressure.
Problem summary: developers must deploy services but often don’t know the right CPU/memory values. They guess—and guessing typically goes two ways: overprovision “just to be safe,” or underprovision and hope the workload holds.
The image depicts three people sitting at a table with laptops, thinking about CPU and memory, with the title "The Problem: The Guessing Game" and labeled "Over-provisioned."
Real-world example: an e‑commerce company with 200 microservices on Kubernetes saw a 40% quarterly AWS bill increase even though traffic and revenue didn’t grow proportionally. Investigation revealed many Pods requested 8 CPUs but used only ~0.2 CPU on average.
The image outlines a cost spike problem, highlighting that an AWS bill increased by 40% quarter-over-quarter without proportional growth in revenue, traffic, or infrastructure costs.
That’s 40× overprovisioning per Pod. Why that costs money: the scheduler uses resource requests (not instantaneous usage) when placing Pods. If a Pod requests 8 CPUs, the scheduler reserves those 8 CPUs on the node for placement decisions. Those reserved CPUs can’t be used by other Pods, and the autoscaler may add nodes to satisfy requested capacity—driving cloud spend up.
The image illustrates the "Over-Provision Problem," highlighting that developers requested 8 CPUs per pod, but the actual usage is only 0.2 CPUs.
The image illustrates the financial impact of over-provisioning CPUs for developers, showing a request for 8 CPUs per pod but actual usage is only 0.2 CPUs, leading to 7.8 CPUs sitting unused.
Conversely, omitting limits can be catastrophic during traffic spikes (Black Friday or viral campaigns). A container that consumes free memory can exhaust node RAM. When node memory runs out, the kernel may invoke the OOM killer and Kubernetes marks Pods as OOMKilled—often at the worst possible moment.
The image outlines the issue of under-provisioning in Kubernetes, showing step-by-step scenarios from having no resource limits to service instability during peak demand.
Without proper sizing you get three main operational problems:
  • The scheduler makes poor placement decisions because requests are inaccurate.
  • Pods are evicted unpredictably because limits/requests weren’t planned.
  • Nodes become either starved (no capacity) or idle (wasted capacity), increasing risk or cost.
The image outlines three cascading problems without proper sizing: poor placement decisions by the scheduler, unpredictable pod evictions, and nodes being either starved or wasting resources.
High‑level solution (conceptually simple; requires platform policy + observability):
  1. Set sensible default CPU and memory requests.
  2. Enforce a maximum resource limit per namespace with ResourceQuota.
  3. Require memory limits for containers (memory overcommit is unforgiving).
  4. Right-size using real usage metrics and iterate.
The image outlines a solution with four key components: sensible default CPU/memory requests, maximum resource limits per namespace, required memory limits, and right-sizing based on real usage.
Important clarification: Kubernetes is not aware of your workload’s true needs unless you tell it. The scheduler relies entirely on resource requests for placement decisions. If you omit requests, the scheduler treats the container as claiming zero resources—potentially causing noisy-neighbor problems by scheduling Pods onto already highly utilized nodes. If you omit limits, a container can consume unbounded CPU (subject to CPU isolation behavior) or memory at runtime, affecting co-located workloads. A runaway process (memory leak or unbounded allocation) without limits can crash other workloads on the node. When a Pod has neither requests nor limits defined, it receives the BestEffort QoS class and is the first to be evicted under resource pressure.
The image illustrates Kubernetes resource allocation, showing a default pod with "Requests" and "Limits" set to none, labeled as "BestEffort QoS – First to be evicted", with nodes A and B displayed to the side.
Kubernetes needs explicit resource hints. Quick recap of why each field matters:
  • requests: used by the scheduler to decide Pod placement (affects packing and cluster autoscaler behavior).
  • limits: enforced by the kubelet via cgroups. For CPU, exceeding the limit results in throttling; for memory, exceeding the limit results in an OOM kill.
  • defaults: Kubernetes does not apply automatic sensible defaults; use LimitRange to inject defaults per namespace and ResourceQuota/admission controls to enforce policies.
The image explains why Kubernetes needs explicit resource hints, highlighting issues related to missing requests, limits, and default behavior. It notes that without requests, scheduling decisions are affected; without limits, a pod can crash a node; and default behavior assumes manual configuration.
Best practice: enforce platform-wide defaults using LimitRange and control consumption with ResourceQuota. Combine these with observability to make data-driven adjustments rather than guessing.
Quick reference: QoS class rules Example Pod spec with sensible requests and limits:
Memory limits are critical. Exceeding memory triggers OOM kills that can cascade into customer-visible failures—so require memory limits and monitor tail latencies and OOM events.
Recommended right-sizing workflow (practical, repeatable)
  1. Platform defaults: use LimitRange to inject conservative requests and limits automatically; add ResourceQuota per namespace to cap consumption.
  2. Deploy and collect telemetry: gather CPU, memory, latency, and error-rate metrics over representative traffic patterns (including peaks).
  3. Analyze percentiles: review P50/P95/P99 and tail behavior. Set requests to cover steady-state usage (e.g., P50/P95 depending on tolerance) and limits to protect the node and bound peak behavior.
  4. Automate and iterate: use Horizontal Pod Autoscaler (HPA) for CPU or custom metrics; for memory patterns consider Vertical Pod Autoscaler or automated recommendations. Reassess after major releases and periodically.
In short: this is primarily a governance + observability problem. Provide explicit, sensible resource requests and limits and enforce them at the platform level. Use telemetry to right-size iteratively so the scheduler can make good placement decisions and your cluster remains stable and cost-effective. Links and references

Watch Video