Kubernetes / Pods, Containers & Application Health
Distinguish an OOMKilled container from other abrupt terminations
A container can hit a memory limit even when its node appears to have spare RAM. Inspect the reported last termination and resource settings.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl -n app get pod web-0 -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}{" "}{.status.containerStatuses[*].lastState.terminated.exitCode}'Read the result
The fields describe recorded last terminations, potentially for several containers. Exit code 137 alone does not establish every possible kill source.
Resolve and verify
Correlate the named container with memory metrics, limits and application growth. Fix excessive demand or plan a justified resource change with node capacity in view.
Before changing production
Do not remove all limits or assume current memory after restart represents the failed peak.