How to fix OOMKilled in Kubernetes

Check the container termination status:

kubectl describe pod <pod-name>

Look for the Last State section showing:

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

Also check kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[*].lastState}'

View the current resource configuration:

kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'

Monitor actual memory usage:

kubectl top pod <pod-name>

Note: kubectl top requires metrics-server to be installed in your cluster.

Update your deployment with higher limits based on observed usage:

resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "1Gi"

Set requests to typical usage and limits to handle peak load. A common starting point is limits = 1.5x to 2x the requests value.

Apply changes: kubectl apply -f deployment.yaml

JVM heap is only part of Java memory usage. Account for metaspace, threads, and native memory:

env:
  - name: JAVA_OPTS
    value: "-XX:MaxRAMPercentage=75.0 -XX:+UseContainerSupport"

Or set explicit heap limits lower than container limits:

env:
  - name: JAVA_OPTS
    value: "-Xmx768m -Xms512m"  # For a 1Gi container limit

Leave at least 25% of container memory for non-heap usage.

If limits seem adequate, the application may have a memory leak. Enable profiling:

# For Java, generate heap dump on OOM
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof

For other languages, use appropriate profiling tools. Monitor memory growth over time with Prometheus/Grafana to identify leak patterns.

Set identical requests and limits to get Guaranteed QoS, which has the lowest OOM score:

resources:
  requests:
    memory: "1Gi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "500m"

Guaranteed pods are killed last when a node is under memory pressure. BestEffort pods (no limits) are killed first.