How To Fix Kubernetes Memorypressure [Solved]

Feature	Details
Error Code	MemoryPressure
Type	Node Condition
Main Cause	Node available memory is below the eviction threshold.
Common Impact	Pod evictions, failure to schedule new pods, node instability.
Quick Fix	Increase node resources, optimize Pod resource limits, or restart leaking processes.

Table of Contents

What is Kubernetes MemoryPressure?

MemoryPressure is a specific node condition in Kubernetes indicating that the node is running dangerously low on RAM. When this threshold is crossed, the Kubelet sets the MemoryPressure condition to True.

Once this flag is active, the node stops accepting new pods. Furthermore, the Kubelet begins the process of “eviction,” where it terminates existing pods to reclaim memory and protect the stability of the host system.

Typically, this happens when the available memory on the node falls below the hard or soft eviction thresholds defined in the Kubelet configuration (often 100Mi by default).

Step-by-Step Solutions

1. Identify the Affected Node

First, confirm which node is reporting the pressure. Use the following command to check the node status conditions.

kubectl get nodes -o custom-columns=NAME:.metadata.name,MEMORYPRESSURE:.status.conditions[?(@.type==\"MemoryPressure\")].status

2. Analyze Memory Usage

Determine which pods are consuming the most memory. This requires the Metrics Server to be installed in your cluster.

kubectl top pods --all-namespaces --sort-by=memory

You should also check the memory usage at the node level:

kubectl top nodes

3. Describe the Node for Eviction Events

Review the node events to see which pods were evicted and why. This provides context on whether the pressure is a sudden spike or a slow leak.

kubectl describe node [node-name]

4. Set Resource Requests and Limits

Prevent “noisy neighbors” from consuming all node memory by defining limits and requests in your deployment YAML. This ensures the scheduler places pods on nodes with guaranteed capacity.

resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"

5. Scale the Cluster

If your workloads are legitimately outgrowing your current infrastructure, you must scale. You can either add more nodes to the pool or upgrade the machine type to one with more RAM.

# Example for GKE
gcloud container clusters resize [cluster-name] --node-pool [pool-name] --num-nodes [new-number]

6. Adjust Kubelet Eviction Thresholds

If your nodes are healthy but the eviction is too aggressive, you can tune the Kubelet parameters. Adjust the --eviction-hard flag, though this should be done with caution to avoid system crashes.

# Example Kubelet flag
--eviction-hard=memory.available<500Mi