Overcommitment means the total amount of resources promised to the pods on a node is larger than the amount the node can actually deliver.

A node is one machine in a Kubernetes cluster. It might be a physical server or a virtual machine in the cloud. Every node has a fixed amount of processing power, which we call CPU, and a fixed amount of memory, which we call RAM. Pods are the small packages that run your applications, and each pod asks for some of that CPU and memory. When the sum of what pods are allowed to use is higher than what the node owns, the node is overcommitted.

This sounds dangerous, and sometimes it is. But it is also normal and, in most companies, intentional. Applications rarely use all the resources they could. A web service might be sized for the busiest hour of the year but spend most days using a small part of its allowance. If every pod reserved its worst case, nodes would sit mostly idle and the bill would be huge.

Every container can carry two numbers for each resource, and they do very different jobs.

When you describe a container, you can state a request and a limit for CPU and for memory. These two numbers are often confused, and the confusion causes most overcommitment problems. The request is a promise Kubernetes makes to the container about scheduling. The limit is a ceiling that the node enforces while the container is running. The first is about getting a seat. The second is about how much you may eat once you are seated.

The gap between request and limit

The distance between the request and the limit is called the burst room. A container that requests half a CPU and has a limit of two CPUs may use up to two CPUs when the node has spare capacity. When many containers use their burst room at the same moment, the node can run out, and that is when overcommitment turns from a saving into a problem.

The scheduler is the part of Kubernetes that picks a node for each new pod, and it does arithmetic using requests only.

When a pod is created, the scheduler looks at every node and asks a simple question: after adding the requests of the pods already on the node, is there still enough room for this new pod’s requests? Room is measured against a number called allocatable, which we will explain in the next chapter. If the answer is yes, the node is a candidate. The scheduler then picks the best candidate using extra scoring rules.

Notice what the scheduler does not look at. It does not look at the limits when deciding whether a pod fits. It does not look at how much CPU or memory the existing pods are actually using right now. It only adds up the numbers people wrote down as requests. This is why requests are the most important numbers in a cluster, and why wrong requests cause so many surprises.

flowchart LR
  A["New pod with requests and limits"] --> B["Scheduler reads requests only"]
  B --> C["Sum requests of pods on each node"]
  C --> D{"Fits within allocatable?"}
  D -- "Yes" --> E["Node is a candidate"]
  D -- "No" --> F["Node is skipped"]
  E --> G["Best scoring node is chosen"]
        

Two ways to get it wrong

Not all of a machine belongs to your pods. Some of it is kept back for the system itself.

Imagine a machine with sixteen units of memory. You might assume your pods can use all sixteen. In reality, the operating system needs memory to run. The Kubernetes helper program on each node, called the kubelet, needs memory. The container runtime, which actually starts containers, needs memory too. If your pods used every last unit, these essential programs would starve, and the whole node could become unresponsive.

Kubernetes handles this by subtracting reserved space from the total. The result is called allocatable, and it is the number the scheduler uses. Three kinds of reservation are commonly subtracted. One is set aside for Kubernetes system programs. One is set aside for the operating system’s own programs. The third is a safety margin called the eviction threshold, which is the amount of free memory the kubelet tries to keep so it has time to react before the machine runs dry.

flowchart TD
  A["Node capacity: total physical resources"] --> B["Minus kube-reserved for Kubernetes programs"]
  B --> C["Minus system-reserved for operating system"]
  C --> D["Minus eviction threshold safety margin"]
  D --> E["Allocatable: the space pods may be promised"]
        

Why small nodes lose more

The reserved amounts are not a fixed percentage. Some of the reservation is a flat amount that every node pays no matter how big it is. That means small nodes lose a larger share to overhead than big nodes. A tiny machine might lose a quarter of its memory, while a large machine might lose only a few percent. This is one reason node size matters when you plan how much overcommitment you can safely allow.

CPU is called compressible, which means that when there is not enough, programs slow down but do not die.

CPU time is like a road shared by many cars. When there are more cars than lanes, everyone moves slower, but nobody is destroyed. This is why experts call CPU a compressible resource. If a node runs short of CPU, pods simply get less processing time each, and requests take longer to answer. That is annoying, but usually recoverable.

Kubernetes uses two different mechanisms for CPU, one for the request and one for the limit. The request is turned into a weight. When several containers want CPU at the same time, the kernel shares the processing time in proportion to those weights. A container with a request twice as large as its neighbor’s gets about twice the share when the machine is busy. When the machine is not busy, containers can use more than their request freely.

The CPU limit works differently

The limit is not a weight. It is a hard cap enforced by dividing time into small windows, commonly one tenth of a second. In each window, the container receives a quota of CPU time. Once the container has used its quota, it is paused until the next window begins, even if the machine is completely idle. This pausing is called throttling. A throttled container does not crash, but it stops working for part of each window, and the pauses can add noticeable delay to every request it handles.

Memory is incompressible. When it runs out, something must be killed.

Memory behaves very differently from CPU. A program that holds data in memory cannot work with less memory the way it can work with less CPU time. You cannot shrink a loaded photo or an open database table and expect the program to carry on. When the machine truly runs out of memory, the operating system has only one option: it must stop some program to free memory. This is why experts call memory an incompressible resource, and why memory overcommitment is far more dangerous than CPU overcommitment.

When a container tries to use more memory than its limit, the kernel stops it immediately. This event is called an out-of-memory kill, usually written as OOM kill. Kubernetes then notices the container died and restarts it according to the pod’s rules, and the pod’s status often shows the reason as out of memory. If the application keeps using too much memory, it will be killed again and again, and the pod will seem to be stuck in a restart loop.

Two kinds of memory kill

The second case is the real danger of memory overcommitment. A node can have thirty pods, each safely under its own limit, and still run out of memory because the sum of their real usage exceeds the machine’s total. That is exactly the full-flight situation of our airline analogy.

Kubernetes sorts every pod into one of three classes, and the class decides who is protected when things go wrong.

You never choose a quality-of-service class directly. Kubernetes assigns it automatically based on how you wrote the requests and limits. The class is then used by the node to decide which pods are most important to keep alive and which are the first to lose their place. Understanding the three classes is the key to predicting what will happen during a crunch.

When a node starts to run out of something, the kubelet steps in and removes pods on purpose to protect the machine.

The kubelet, the Kubernetes helper program on each node, constantly watches key signals such as how much memory is free, how much disk space is free, and how many process slots are left. You can set thresholds for these signals. When a signal crosses a threshold, the kubelet marks the node as under pressure and begins to evict pods, which means it stops them and asks the cluster to run them somewhere else.

flowchart TD
  A["Kubelet watches signals"] --> B{"Threshold crossed?"}
  B -- "No" --> A
  B -- "Soft threshold" --> C["Wait for grace period"]
  B -- "Hard threshold" --> D["Act immediately"]
  C --> E["Mark node under pressure"]
  D --> E
  E --> F["Stop new pods from scheduling here"]
  F --> G["Rank pods and evict until signal recovers"]
        

Soft and hard thresholds

A soft threshold gives pods a grace period. The kubelet waits to see whether the pressure goes away on its own, and if it does not, it begins a gentle shutdown that gives pods time to finish. A hard threshold has no waiting. The kubelet acts at once, because the machine is close to trouble. Most clusters have a default hard threshold for free memory, and teams that run overcommitted nodes usually tune these numbers carefully.

Who is evicted first?

When the kubelet must pick victims, it follows a clear order. Pods using more than they requested are considered before those within their request. Among those, lower priority pods go first. Among pods of equal priority, the ones using the most beyond their request go first. This is the practical meaning of the quality-of-service classes: BestEffort pods have no request, so any usage exceeds it, and they are first in line.

Two different systems can stop your pods for lack of memory, and they behave very differently.

People often use the words eviction and OOM kill as if they meant the same thing. They do not. An eviction is a polite, planned action by the kubelet. An OOM kill is a sudden action by the operating system kernel. Knowing which one happened tells you where to look for the cause.

The kernel’s scoring list

Linux keeps a score for each process that says how willing the system is to kill it when memory runs out. Kubernetes sets these scores according to quality-of-service class. Guaranteed pods receive a very protective score. BestEffort pods receive the highest score, so they are chosen first. Burstable pods receive a score that depends on how large their memory request is compared to the node, so pods with larger requests are somewhat safer. This is the second layer of protection after kubelet eviction and it matters when memory runs out faster than the kubelet can react.

CPU and memory get the attention, but nodes can run out of other things too.

A node has other limited resources that pods can exhaust. Pods use temporary disk space for logs, caches and scratch files, called ephemeral storage. Pods also create processes, and each node can only keep track of so many. If a single pod uses too many of these, the whole node suffers, and the kubelet reports it as disk pressure or process-slot pressure.

If overcommitment is risky, why does almost every large cluster do it? Because the alternative is expensive waste.

Studies and field reports from many organizations repeatedly show that most Kubernetes clusters use a small fraction of the CPU and memory that is requested for them. Teams ask for generous amounts to feel safe, and then the applications use far less on a typical day. If the cluster honored every request as a true reservation of real usage, most of the money spent on machines would buy idle capacity.

Benefits of a planned overcommit

Statistical multiplexing in plain words

The idea behind safe overcommitment has a fancy name, statistical multiplexing. It simply means that when many independent workloads share a resource, their peaks rarely line up. One service is busy in the morning, another at night, a batch job runs at midnight. Added together, the total demand is smoother and lower than the sum of every individual peak. The more independent the workloads, the safer the bet.

You cannot manage a risk you have not measured. A few simple ratios tell you exactly where you stand.

To measure overcommitment, you compare three totals for each node or for the whole cluster: the sum of requests, the sum of limits, and the real usage. All three are compared against allocatable. Each ratio answers a different question and together they give a complete picture.

flowchart LR
  A["Sum of limits: promised burst room"] --> D["Allocatable: what the node can really give"]
  B["Sum of requests: what the scheduler counted"] --> D
  C["Real usage: what pods consume now"] --> D
  D --> E["Compare the three to judge risk"]
        

Reading the results

The worst overcommitment stories are rarely about one pod. They are about one pod hurting many others.

A noisy neighbor is a pod that uses so much of a shared resource that other pods on the same node suffer. With CPU, neighbors see slower response times. With memory, neighbors may be evicted. With disk and network, everyone’s input and output slows. Since the pods are different applications owned by different teams, nobody sees the connection until someone digs deep.

The cascading failure

The most dangerous pattern is the cascade. A node comes under memory pressure and evicts several pods. Their controllers recreate them on other nodes. Those nodes now receive extra load and may also reach their thresholds. They evict pods, which move again, and the problem spreads across the cluster like a falling row of dominoes. Meanwhile, applications that restart need extra CPU and memory to start up, which adds further pressure.

flowchart TD
  A["Node A under memory pressure"] --> B["Pods evicted from Node A"]
  B --> C["Pods rescheduled onto Node B and C"]
  C --> D["Startup spikes add load to B and C"]
  D --> E["Node B reaches pressure"]
  E --> F["More evictions and restarts"]
  F --> C
        

Should you set CPU limits at all? Experienced teams disagree, and understanding both sides is part of mastering overcommitment.

Because CPU limits cause throttling even when the machine is idle, many experienced engineers recommend setting CPU requests carefully but leaving CPU limits off for most workloads. Their reasoning is that CPU is compressible, requests already guarantee a fair share when the node is busy, and limits only add pauses when there is spare capacity that could have been used for free.

Other teams keep CPU limits for good reasons. Limits give predictable behavior, which is valuable for performance testing. They stop a runaway program from consuming a whole node. And they are required to reach the Guaranteed class, which has special benefits such as exclusive CPU cores when the node uses a static CPU management policy.

A sensible middle path

For memory, the safest overcommit strategy is to be honest in requests and generous but not unlimited in limits.

Because memory cannot be squeezed, overcommitting it is far riskier than overcommitting CPU. A widely used practice is to set the memory request equal to the memory limit for important workloads. This removes burst room for memory, so the pod’s maximum use is known to the scheduler, and the node cannot be surprised by the pod growing past what was counted. Such pods may still be Burstable if CPU is configured differently, but their memory behavior is fully predictable.

How to choose the memory request

A good starting point is to observe the real memory usage of the application over a typical busy period, including startup and any scheduled heavy tasks, and set the request to cover its normal peak with a small margin. If you set it too low, the node counts too little and packs too many pods. If you set it too high, you waste money, but the pod is safe.

How to choose the memory limit

Choose a limit that is above the highest healthy usage but not so far above that a bug could eat a whole node. Programs written in languages that manage memory automatically need extra care. Their own settings for how much memory they may take should be aligned with the container limit, otherwise the program may believe it has more memory than the container allows and be killed unexpectedly.

Good habits are easier when the platform enforces them. Kubernetes offers two namespace-level tools for exactly that.

Asking every developer to write sensible requests and limits works for a while, and then someone forgets. Two built-in tools help the platform team make good behavior automatic. A LimitRange sets defaults and boundaries for each pod or container in a namespace. A ResourceQuota sets a total budget for the whole namespace.

Controlling the overcommit ratio

The LimitRange can set a maximum ratio between limit and request. For example, a platform team may say that no container may have a memory limit more than one and a half times its request. This is a very direct way to cap overcommitment, because it prevents the huge gaps that create hidden risk. Different namespaces can have different ratios, so a sandbox can be generous while production is strict.

Humans are bad at guessing resource needs. Automatic tools can watch real usage and suggest better numbers.

Few people can predict how much CPU and memory an application will use. They usually guess high, and the guess becomes permanent. Kubernetes has several autoscaling tools that adjust capacity based on what really happens, and each works on a different level.

flowchart LR
  A["Real usage over time"] --> B["Vertical autoscaler: right size each pod"]
  A --> C["Horizontal autoscaler: right number of pods"]
  B --> D["Accurate requests"]
  C --> D
  D --> E["Cluster autoscaler: right number of nodes"]
        

Be careful when mixing them

The horizontal autoscaler uses usage as a percentage of the request. If the vertical autoscaler keeps changing the request on the same metric, the two can chase each other and cause unstable behavior. A common rule is to avoid letting both act on the same resource for the same workload, or to use the vertical tool only in recommendation mode and apply its advice through your normal review process.

Choosing the size of your machines changes how much overcommitment you can survive.

Fitting pods onto nodes is a packing puzzle called bin packing. Think of nodes as boxes and pods as items of different sizes. Your goal is to fill the boxes well without breaking any. The size of the box matters a great deal. Small boxes waste more space on overhead and leave awkward gaps, and big boxes pack tightly but make each box failure more painful.

Match nodes to workload shape

Some workloads need a lot of memory for each unit of CPU, such as caches and databases. Others need a lot of CPU for each unit of memory, such as encoding and calculation. If your nodes have a fixed ratio between the two that does not match the workload, one resource runs out while the other sits idle. This is called stranded capacity. Choosing machine families whose CPU to memory ratio fits the workload recovers real money.

When room runs out, some pods matter more than others, and Kubernetes lets you say which.

A priority class is a named number that you attach to pods. Higher numbers mean more important. Priority affects two moments. When the scheduler cannot find room for an important pod, it can preempt, which means it removes one or more lower-priority pods from a node to make room. And when a node is under pressure, priority is one of the factors the kubelet uses to decide whom to evict.

Priority makes overcommit safer

A powerful pattern is to fill leftover capacity with low-priority work. These pods use space that would otherwise be idle, so utilization rises. When an important pod needs room, the low-priority pods are preempted and the important pod is placed quickly. You get the money savings of high utilization while the important workloads stay protected.

Kubernetes has long avoided swap, but the story is changing, and it is worth understanding why.

Swap is disk space that the operating system can use as emergency memory. When real memory runs low, less used data is written to the disk to make room. Disk is much slower than memory, so a heavy swapper feels sluggish, but it may survive where it would otherwise be killed. For years, Kubernetes required nodes to have swap turned off, because it made resource accounting unpredictable, and a pod using swap breaks the clean idea that a memory limit is a hard wall.

More recently, Kubernetes has added optional, controlled swap support that is designed to be safer, with swap offered mainly to pods in certain classes. Details such as which classes are eligible, default behavior and feature maturity have changed from release to release. Always check the documentation for your version before relying on it.

Overcommitment is safe only when you can see the early warning signs.

Because overcommitment depends on real usage staying below real capacity, monitoring is not a nice extra. It is the safety system. The signals fall into four families: how full the node is, how hard containers are being squeezed, how often pods are being removed, and how accurate your requests are.

Pressure stall information

Modern Linux kernels can report how much time tasks spend waiting because a resource is short. This is called pressure stall information. It is more honest than a usage percentage, because a node can show moderate usage while tasks still wait. If CPU, memory or disk pressure numbers start rising, the node is already hurting even if it has not crossed an eviction threshold.

Not every workload should share a node. Separating them is the simplest way to control the blast radius of overcommitment.

A node pool is a group of nodes with the same shape and purpose. By using labels, taints and tolerations, you can steer pods onto the pool that suits them and keep unlike workloads apart. This lets you run aggressive overcommitment where failure is cheap and conservative settings where failure is costly.

flowchart TD
  A["Cluster"] --> B["Critical pool: Guaranteed pods, no overcommit"]
  A --> C["General pool: Burstable pods, moderate overcommit"]
  A --> D["Batch pool: BestEffort and low priority, high overcommit"]
        

When many teams share a cluster, overcommitment is not only a technical question. It is a question of who pays and who is protected.

In a shared cluster, a team that over-requests wastes money that everyone else’s bill carries, and a team that under-requests pushes risk onto its neighbors. Without feedback, teams have little reason to improve. Cost visibility changes behavior: when each team can see how much of its requested capacity it actually uses, over-requesting becomes something people notice and fix.

Experienced teams keep meeting the same good and bad shapes. Learn them early.

Patterns that work

Patterns that hurt

If you are starting from a messy cluster, here is a calm order of work that raises efficiency without breaking anything.

Most overcommitment problems show up as one of four complaints. Each has a short list of checks.

Complaint 1: “My pod keeps restarting”

Complaint 2: “My pod was evicted”

Read the status message, which names the signal, such as low memory or low disk. Then check node conditions and recent usage on that node. Look at the pod’s class and how far above its request it was running. If eviction repeats, either raise the request so the pod is better protected and the scheduler places it on a roomier node, or reduce density on the nodes.

Complaint 3: “My service is slow but nodes look idle”

Look for CPU throttling on the container. A tight CPU limit can pause a container even while the node is quiet. Compare the limit with the container’s peak needs. Consider raising the limit or removing it for latency-sensitive services, then watch the throttling metrics fall.

Complaint 4: “Pods are pending though the cluster looks empty”

The scheduler counts requests, not usage. Nodes may be fully requested even though they are mostly idle. Find the over-requested workloads and right-size them, or add capacity if the requests are accurate.

For the most sensitive workloads, Kubernetes can give a pod its own private CPU cores that nobody else may touch.

Normally, many pods share all the CPU cores of a node, and the kernel moves their work around freely. That sharing is what makes CPU overcommitment possible. But some applications, such as trading systems, telephone switching and high-speed packet processing, suffer when their work keeps moving between cores. For them, a node can run a static CPU management policy. Under this policy, a pod in the Guaranteed class that asks for a whole number of CPUs is given exclusive cores, and other pods are kept off those cores.

The right amount of overcommitment depends on how much spare room you keep for bad days.

Headroom is the unused capacity you deliberately keep. It absorbs traffic spikes, node failures and rollouts. A cluster with no headroom has no way to survive an unexpected event. A cluster with huge headroom wastes money. The art of capacity planning is picking the smallest headroom that still lets you survive your realistic worst days.

Think in failure zones

Cloud clusters are often spread across several failure zones, which are separate data center areas. If one zone fails, all the nodes there disappear together, and their pods must be placed on the remaining zones. If you have three zones and run each at high density, the loss of one zone requires the other two to absorb fifty percent more load. That is impossible if they were already near full. This simple arithmetic tells you how much headroom to keep.

Other uses of headroom

A short checklist of habits that separate calm clusters from stressful ones.

Three questions before changing any number

Different industries accept different levels of overcommitment because their cost of failure differs.

Kubernetes writes the numbers down, but the Linux kernel is the one that actually enforces them.

Kubernetes itself does not slow down or stop containers. It translates the requests and limits you wrote into settings for a Linux feature called control groups, usually shortened to cgroups. A control group is a labeled bucket that the kernel keeps around a set of processes. The kernel tracks how much CPU, memory and other resources each bucket is using and applies the rules attached to that bucket. Every container gets its own bucket, every pod gets a larger bucket that holds its containers, and quality-of-service classes get buckets above that.

flowchart TD
  A["Node root bucket"] --> B["Guaranteed pods bucket"]
  A --> C["Burstable pods bucket"]
  A --> D["BestEffort pods bucket"]
  C --> E["Pod bucket"]
  E --> F["Container bucket with limit settings"]
        

What each setting becomes

Why a memory request is not a reservation

Many people believe that a memory request puts that memory aside for the pod. By default it does not. The kernel does not hold physical memory back for a container just because it asked. The request is used by the scheduler to count room and by the node to rank pods under pressure. This is one more reason why the real usage of all pods, not only the sum of requests, decides whether a node is safe.

Numbers make the ideas stick. Let us follow one small node from empty to overcommitted.

Imagine a node with sixteen gigabytes of memory and eight CPU cores. The team reserves one gigabyte of memory for the system and the kubelet, and keeps a half gigabyte as an eviction margin. That leaves fourteen and a half gigabytes of allocatable memory. Suppose seven cores are allocatable on the CPU side after similar reservations.

Step 1: Place the pods

The team places ten identical pods on the node. Each asks for one gigabyte of memory and half a core as a request, and has a limit of two gigabytes and one core. The scheduler adds up requests: ten gigabytes of memory and five cores. That fits inside fourteen and a half gigabytes and seven cores, so all ten pods are accepted, and there is still room for a few more.

Step 2: Count the promises

Now add up the limits. Ten pods with two gigabyte limits make twenty gigabytes of memory limit. Ten pods with one core limits make ten cores of CPU limit. Compared with allocatable, the memory limit total is about one hundred and thirty-eight percent and the CPU limit total is about one hundred and forty-three percent. The node is overcommitted on both resources, even though requests show it is only about seventy percent full.

Step 3: Watch a good day and a bad day

Overcommitment is one lever in a larger cost story, and it works best together with the others.

Cloud bills depend on how many machines you rent, what kind they are and how you pay for them. Overcommitment reduces the number of machines by packing more work onto each one. But there are other levers, and they interact. Understanding how they fit together helps you choose where overcommitment belongs.

Matching levers to workloads

Resources are also a security topic, because a program that can use unlimited resources can hurt everyone around it.

On a shared node, a program that consumes too much memory, too many processes, too much disk or too much processor time can deny service to its neighbors. This can happen by accident, as in a bug, or on purpose, as in an attack. In a cluster where teams do not fully trust each other, or where customers run their own code, resource limits are a security control as much as a cost control.

Defensive habits

Half the confusion about resources comes from the units. A short lesson in reading them removes a lot of mistakes.

Kubernetes measures CPU in cores and fractions of cores. One whole core is written as one. A tenth of a core is written as one hundred millicores, where a millicore is a thousandth of a core. So five hundred millicores is half a core, and two thousand millicores is two cores. A container asking for a tiny amount, such as ten millicores, wants only a hundredth of one core, which is enough for a very quiet helper process.

Memory is measured in bytes, with friendly suffixes. There are two families of suffixes, and mixing them up causes quiet errors. The decimal family uses powers of one thousand, and the binary family uses powers of one thousand and twenty-four. A mebibyte is slightly larger than a megabyte, and a gibibyte is slightly larger than a gigabyte. The difference is small for small numbers but grows as numbers grow, and a limit written in one family can be a few percent different from the same-looking number in the other.

Why units cause real incidents

A small typing slip can change a number by a huge factor. A memory limit written with the wrong suffix can become a thousand times smaller than intended, and the container is killed the moment it starts. A CPU request written as a whole number when a fraction was meant can claim many times more room than needed and block other pods. Reviewing the units in a change is as important as reviewing the logic.

The program inside the container must understand the box it lives in, or it will misbehave.

Many programs decide how much memory and how many worker threads to use by looking at the machine they run on. Inside a container, the machine they see may be much bigger than the slice they are allowed to use. A program that thinks it owns thirty-two cores may start thirty-two worker threads even though the container is limited to one core, and the result is heavy throttling. A program that thinks it owns a huge amount of memory may grow its internal storage far beyond the container limit and be killed.

Leave a gap between runtime and limit

A program’s total memory is more than its main heap. It also includes code, thread stacks, buffers and internal bookkeeping. If you set the heap maximum equal to the container limit, the extra pieces push the total over the limit and the container is killed. A common habit is to set the program’s own memory target to a comfortable fraction of the container limit and leave the rest as a safety margin for everything else.

Many resource incidents happen not in steady state but in the moments when pods start or change.

An application often needs far more CPU and memory in its first seconds than later. It loads code, warms caches, opens connections and sometimes compiles parts of itself. If its request is sized for the quiet steady state, the node does not count that startup burst, and when many pods start at once the node can be overwhelmed. This is common during a rolling update, a node drain or after a failure, when many replacement pods start together.

How probes make things worse

Kubernetes uses probes to check whether a container is alive and ready. If a container is slow to start because the node is busy, and the probe gives up too early, Kubernetes restarts the container. The restart causes another startup spike, which keeps the node busy, which slows the next start, and a restart loop can feed on itself. This is a classic way for a mild shortage to become a long outage.

flowchart TD
  A["Node is busy"] --> B["Container starts slowly"]
  B --> C["Probe times out"]
  C --> D["Container is restarted"]
  D --> E["Another startup spike"]
  E --> A
        

Short, direct answers to the questions people ask most often when they first meet node overcommitment.

No. It is a deliberate trade-off that saves money by letting workloads share idle capacity. It becomes bad when it is accidental, unmeasured or applied to memory without a safety margin.

No. The scheduler fits pods using requests only. Limits are enforced later by the node while the container runs, which is exactly why the sum of limits can exceed what the node owns.

It is throttled, meaning it is paused for part of each time window. It is not killed, but it can become noticeably slow.

The kernel kills it with an out-of-memory event, and Kubernetes restarts it according to its restart rules.

Pods using more than their request go first, and among them the lower priority ones, so BestEffort pods and heavily bursting Burstable pods are the first victims. Guaranteed pods are the most protected.

Every container in the pod must have both a CPU and a memory request and limit, with the request equal to the limit for each.

Many teams remove them for latency-sensitive services to avoid throttling, while keeping accurate requests. Keep them for batch, untrusted or exclusive-core workloads. Measure throttling before and after any change.

The scheduler counts requests, not usage. Nodes can be fully requested yet nearly idle if requests are padded. Right-size the requests to free the room.

There is no universal number. It depends on how independent your workloads are, how spiky they are and how costly failure is. Keep memory requests close to real usage and overcommit memory only with a measured margin.

Yes. A LimitRange can set a maximum ratio between limit and request for containers in a namespace, which directly caps hidden overcommitment.

They help, but they do not replace good requests. They react to usage and pending pods, and they take time. You still need accurate requests, headroom and monitoring.

The request. It decides placement, protection under pressure and the scheduler’s picture of every node, so honest requests make nearly everything else easier.

Node overcommitment is the practice of promising, through limits, more CPU and memory than a machine can deliver at once, betting that workloads will not all peak together. It saves money because most applications use far less than they could. It is safe when requests are honest, memory is treated with respect, system space is reserved, priorities protect what matters, headroom survives a node or zone failure, and monitoring watches the warning signs. It is dangerous when requests are empty, memory gaps are huge, nodes run near full, and nobody looks at the numbers after launch.