Requests & limits

Being a good neighbor.

Because many apps share a cluster’s machines, being a good neighbor matters — an app that grabs all the CPU or memory can starve the others. Requests and limits are how you declare what each app needs and caps what it can take, and setting them is one of the most impactful habits for a healthy cluster.

Requests reserve, limits cap

You set two numbers per container. A request is what the container needs and is guaranteed — the scheduler uses the sum of requests to decide which node has room, effectively reserving that much for your app. A limit is the maximum the container may use — if it exceeds its memory limit it gets stopped (out-of-memory killed), and if it exceeds its CPU limit it is throttled (slowed, not killed, because CPU can be shared moment to moment while memory cannot). Together they make sharing fair and predictable: requests ensure your app is placed somewhere it actually fits and gets the resources it needs, and limits stop any one container from running away and hurting its neighbors on the same node. Without requests, the scheduler is guessing and can overpack a node; without a memory limit, one leaky app can consume a whole machine and take others down with it.

spec:
  containers:
    - name: web
      image: my-app:1.4
      resources:
        requests: { cpu: 250m, memory: 256Mi }   # guaranteed + used to place the pod
        limits:   { cpu: 500m, memory: 512Mi }    # ceiling: mem over = killed, cpu over = throttled
# 250m = a quarter of one CPU core; 256Mi = 256 mebibytes of memory.

Why setting these matters

Getting requests and limits right pays off in several ways you have already touched. Scheduling works properly — the scheduler can place your pods on nodes that genuinely have room, so you avoid the surprise of pods that will not start or nodes that fall over from overcommitment. Autoscaling works — remember the Horizontal Pod Autoscaler measures usage against the request, so without requests it cannot scale on utilization at all. And stability improves — memory limits protect a node from a single runaway container, keeping the whole machine (and everyone else’s pods on it) healthy. There is a balance to strike: set requests too low and the scheduler overpacks nodes and apps fight; set them too high and you waste capacity on reservations you never use. A reasonable habit for beginners is to always set requests (so scheduling and autoscaling work), set a memory limit (so one app cannot eat the node), and be a little cautious with tight CPU limits (throttling a healthy app can hurt). This is where being a considerate cluster citizen becomes concrete — and it rounds out fundamentals nicely: you now know how to run apps, configure them, connect them, store their data, organize them into namespaces, and size them to share the cluster fairly.