Requests, Limits, and the Throttling Trap: K8s Resources for Node.js

You set a CPU limit on your pod, the node has plenty of capacity to spare, and yet your Node.js service is throttled to a crawl. How does that happen? The answer lives deep in the Linux kernel, in the CFS bandwidth controller and cgroups, and most teams never look there. Requests and limits are not two knobs for the same thing. One drives scheduling, the other enforces a hard quota, and confusing them is how you end up paying for CPU you can never actually use. So how do you size them right for an event-loop runtime?

In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina break down how Kubernetes CPU and memory allocation actually works, what requests and limits really do at the kernel level, and why the defaults quietly sabotage Node.js workloads.

In this episode, we cover:

✅ What CPU requests and limits actually mean, and why they are not interchangeable.

✅ How CFS quota and cgroups cause throttling even when the node is mostly idle.

✅ The three QoS classes (Guaranteed, Burstable, BestEffort) and which one fits a Node.js service.

✅ Why a single-threaded runtime makes limit sizing trickier than it looks, and the patterns that avoid silent throttling.

The takeaway?

Kubernetes will give you exactly what you asked for, including the throttling you did not mean to ask for. Get requests and limits right and your Node.js services run predictably. Get them wrong and you will burn money on capacity the scheduler will never let you touch.