MemoryPressure: The node is low on available memory and has started protecting itself

MemoryPressure means the node crossed the kubelet's memory eviction threshold. New pods stop being scheduled there and existing pods begin being evicted, worst QoS class first.

Applies to: All Kubernetes versions

What it means

The kubelet monitors available memory on the node and compares it against configured eviction thresholds. When available memory falls below the hard threshold, the condition becomes true, a taint is applied so the scheduler avoids the node, and the kubelet starts evicting pods to reclaim memory. Selection is ordered: BestEffort pods first, then Burstable pods exceeding their requests, then Guaranteed pods. This is distinct from an OOM kill, which is the kernel acting on a single container that exceeded its own limit — node pressure is the kubelet acting on the node's behalf, and it can remove pods that are entirely within their own limits.

Most common causes

• The sum of what pods actually use exceeds what the node can supply, usually because requests were set well below real usage.
• Pods with no memory requests at all, which are scheduled without regard to what they will consume.
• A memory leak in one workload gradually consuming the node.
• Insufficient kubelet and system reservations, so Kubernetes schedules into memory the operating system needs.
• Page cache and tmpfs usage counting against available memory.
• Too many pods packed onto a node relative to its size.

How to diagnose it

1. Confirm the condition and its message: kubectl describe node NODE.
2. See what is actually consuming memory: kubectl top pods --all-namespaces --sort-by=memory, filtered to that node.
3. Compare requests against usage — a large gap in either direction is the usual root cause.
4. Check the kubelet's eviction thresholds and reservations in its configuration.
5. Look at the eviction events on the node to see which pods were removed and in what order.

How to fix it

1. Set memory requests that reflect measured usage on every workload. Requests are what the scheduler uses, so wrong requests mean wrong placement.
2. Set limits so no single workload can consume the node, and accept that this means it will be OOM-killed rather than taking everything down with it.
3. Configure kubeReserved and systemReserved so the node's own processes are not competing with pods for the last of the memory.
4. Reduce pod density, or use larger nodes if the workload mix genuinely needs it.
5. Fix leaking workloads rather than adding capacity around them.

Notes

A node under memory pressure evicts BestEffort pods first, and a pod with no resource requests at all is BestEffort by definition. Omitting requests is therefore not a neutral choice — it is a choice to be evicted first.

Related

• Evicted — Pod removed because the node ran short of resources
• OOMKilled — Killed by the kernel for exceeding the memory limit

Sources

• Kubernetes documentation — Node-pressure Eviction
• Kubernetes documentation — Reserve Compute Resources for System Daemons
• Kubernetes documentation — Quality of Service for Pods