How to fix Exit Code 137 in Kubernetes

Check if the container was OOMKilled:

kubectl describe pod <pod-name>

Look for these indicators in the output:

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

If Reason shows OOMKilled, it's a memory issue. If it shows Error, check for other causes like liveness probe failures.

View the pod's memory limits:

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

Monitor actual memory consumption:

kubectl top pod <pod-name>

Compare actual usage to limits. If usage approaches limits before crashes, the limits are too low.

Update your deployment with appropriate memory limits:

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

Set requests based on typical usage and limits for peak load. Start with limits at 1.5-2x your observed normal usage. Apply and monitor:

kubectl apply -f deployment.yaml
kubectl top pod <pod-name> --watch

If memory grows continuously until OOM, investigate leaks:

# Watch memory over time
kubectl top pod <pod-name> --watch

For Java applications, enable heap dumps:

env:
  - name: JAVA_OPTS
    value: "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof"

Use language-specific profilers (pprof for Go, memory_profiler for Python) to identify leak sources.

Aggressive liveness probes can also cause exit code 137 if they kill the container:

kubectl describe pod <pod-name> | grep -A 10 "Liveness"

If probes are too aggressive, adjust timeouts:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 30
  timeoutSeconds: 10
  failureThreshold: 3

Pods with Guaranteed QoS are killed last during node memory pressure:

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

When requests equal limits, the pod gets Guaranteed QoS class. BestEffort pods (no limits) are killed first.