How to fix MemoryPressure in Kubernetes

Check node status:

kubectl get nodes
kubectl describe node <node-name>

Look for "MemoryPressure" with True status. The describe output shows:
- Available memory
- AllocatedResources (CPU and memory reserved by pods)
- Conditions section with timestamps

List pods on the affected node and their actual memory usage:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=<node-name>
kubectl top pods -A --sort-by=memory | grep <node-name>

Compare actual usage (from kubectl top) to requested limits. Identify which pod(s) consume the most memory.

For each high-memory pod:

kubectl describe pod <pod-name> -n <namespace>

Check the Limits and Requests sections. If a pod requests 2Gi but uses 4Gi, you have either:
1. Underestimated resource request (normal workload needs more memory)
2. Memory leak (application consuming unbounded memory over time)

Check logs for memory-related warnings:

kubectl logs <pod-name> -n <namespace> | grep -i memory

SSH into the node and check memory allocation:

df -h  # Check disk (often uses page cache memory)
free -h  # Show memory breakdown
ps aux --sort=-%mem | head -20  # Top memory-consuming processes

Look for:
- containerd or docker processes using excessive memory
- System caches (page cache in "cached" column)
- Kernel modules or systemd services consuming memory

If the node has 16Gi total and kubelet reserves 1Gi for system, only 15Gi is available to pods.

Check current eviction thresholds:

kubectl describe node <node-name> | grep -A5 Allocatable
kubectl get --raw /api/v1/nodes/<node-name>/proxy/configz | grep -A5 eviction

Default: --eviction-hard=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

If eviction triggers too early, adjust on the kubelet:

# On the node, edit /etc/kubernetes/kubelet.env or systemd drop-in
--eviction-hard=memory.available<500Mi  # More conservative
--eviction-soft=memory.available<1Gi  # Graceful eviction threshold
--eviction-soft-grace-period=memory.available=1m

Restart kubelet after changes.

Option A: Move pods to another node:

kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
kubectl cordon <node-name>  # Prevent new scheduling

Pods are rescheduled to other nodes. Then:

kubectl uncordon <node-name>  # Re-enable after fixing memory

Option B: Scale down deployments to reduce memory footprint:

kubectl scale deployment <name> --replicas=1

Option C: Add a new node to the cluster with higher memory capacity.

Option D: Increase memory on the existing node (VM resize in cloud provider).

If a specific pod consumes ever-increasing memory:

1. Check application logs for warnings:

kubectl logs <pod-name> --tail=100

2. Profile memory inside container:

kubectl exec -it <pod-name> -- top  # Real-time process memory
kubectl exec -it <pod-name> -- free -h  # Container memory view

3. Common causes in applications:
- Unbounded caches without TTL
- Accumulated data in lists/maps (connection pools, request queues)
- File handles not closed
- Third-party library memory leak

4. Solutions:
- Add memory limits to trigger pod restart:

resources:
  limits:
    memory: "512Mi"

- Implement periodic cleanup or cache eviction
- Use memory profiler (Python: memory_profiler, Node: node --prof)
- Update library to latest bug-fix version

Set up cluster-wide monitoring:

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

Enable automated remediation:
- Descheduler: Evicts pods from overcommitted nodes
- VPA (Vertical Pod Autoscaler): Recommends optimal resource requests
- HPA (Horizontal Pod Autoscaler): Scales replicas based on metrics

Set resource requests and limits on all deployments:

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

Monitor with Prometheus and alert on high memory usage:

kubelet_node_status_condition{condition="MemoryPressure",status="true"}