What Happens When You Don't Set Kubernetes Resource Requests

When you deploy workloads on Kubernetes, it’s easy to skip setting up resource requests at the start. The cluster seems to work fine without them... until it doesn't. In this post, we walk through how requests work, what happens when you ignore them, and why it's worth getting them right.

How Kubernetes Uses Requests

Resource requests tell the Kubernetes Scheduler how much CPU and memory a pod needs to run reliably. The scheduler uses these values during pod placement, only scheduling pods on nodes that have enough available capacity.

If you don’t set requests, Kubernetes assumes the pod needs 0 CPU and 0 memory. That means:

• The scheduler ignores the pod’s real usage and can schedule it on a node that’s already nearly full.
• Once scheduled, the Kubelet just runs it - there’s no dynamic resizing or reallocation if it starts using more resources later.
• If the node runs out of memory, the Linux kernel’s OOM killer will terminate random pods, often the newest ones.

Without requests, the scheduler is flying blind and pods are prone to churn.

Risks of Skipping Requests

In a quiet, steady cluster, it may not be too noticeable. But during high-churn events such as deploy rollouts, spot node cycles, node upgrades, or autoscaler events, skipping requests leads to real problems:

1. Unreliable Scheduling

   • Pods land on nearly full nodes because the scheduler thinks they cost 0
   • For example, during a weekly production deploy of 200 pods, if 10% of nodes are already >80% full, roughly 1 in 10 new pods may land on an overcommitted node and OOM within minutes

2. Pod Churn & OOMKills

   • OOM kills trigger container restarts, which forces the scheduler to place them again, often on equally full nodes
   • This churn delays rollouts and burns compute capacity just rescheduling failing pods

3. User Impact

   • Increased latency while pods restart
   • In-flight requests are dropped when a container dies
   • Autoscaler events take longer because cold starts are slower on contended nodes

4. Operational Overhead

   • Engineers waste time chasing flaky crashes
   • Metrics become unreliable, where CPU and memory graphs may spike randomly because workloads are fighting each other

Simple resource requests can prevent many of these disruption cascades.

Comparison: Benefits of Setting Requests vs. Not

We set up two identical clusters, running the online boutique microservices demo on spot nodes. One had all of the resource requests removed, and while running cyclical traffic simulation, we found the following results:

The behavior on the cluster with resources set was much more steady and consistent:

• Better user experience: Less pod cycling resulted in fewer dropped requests and therefore fewer user-facing errors.
• Predictable performance: Average latency was better even among only successful requests (200s), also due to fewer cold starts.
• Lower costs: Tighter bin-packing improved utilization and resulted in fewer nodes needed.
• Less maintenance: And again if we were a team managing this cluster, we would've need to spend more time firefighting crashes and responding to user inquiries.

In summary - with requests, the cluster was smaller, cheaper, and faster. Without them, it burned more nodes and delivered a worse user experience

Keeping Requests Accurate

It’s worth acknowledging that setting and keeping requests correct can be tedious and frustrating:

• Infra/platform teams often get stuck owning these numbers, or at minimum, they’re responsible for educating feature teams who write and maintain the service configs.
• Over-provisioning everything “to be safe” isn’t a solution either when it drives up cloud costs unnecessarily.

Some practical tips for getting into a good state here:

1. At first, it’s often easier to over-provision with reasonably high numbers, just to establish a baseline.
2. Using kube-state-metrics on Prometheus, build a dashboard showing usage vs. requests to find the greatest offenders.
3. Adjust as needed, or pass on the responsibility to the feature team who owns that service.

Tools like Flightcrew can automate both the upfront work and the long tail of maintaining requests, ensuring they stay aligned with pod and node autoscalers. If that sounds useful, give it a try on flightcrew.io.

Whether you automate it or do it by hand, setting requests is one of the highest-leverage steps you can take to make Kubernetes boring, reliable, and cost efficient.