OOMKilled is the state Kubernetes reports when the kernel terminates a container for exceeding its memory limit. It is a memory problem, and the fix is to understand why the container reached its limit.
OOMKilled means one specific thing: a container tried to use more memory than its limit allowed, so the kernel killed it. The container restarts with no graceful shutdown, which is why it looks like it 'just disappeared'. Troubleshooting is about finding why memory reached the limit, then choosing between raising the limit and fixing the cause.
Check the container's last state: a terminated reason of OOMKilled confirms memory, versus Error (a crash) or other reasons. This distinction matters because the fixes are completely different, an OOMKill is about memory sizing or leaks, an Error is about the application.
Compare the container's memory working set against its limit over time. A slow, steady climb that never drops points to a leak; a sharp spike points to a workload event (a large request, a batch job); a limit that is simply too low for normal operation points to sizing. Each has a different fix.
Ops Singularity ingests Kubernetes memory telemetry over OpenTelemetry and, when a container is OOMKilled, Sentinel AI classifies the pattern and resolves it, right-sizing, rescheduling or escalating with the diagnosis, through a governed, reversible Action Ticket, and can alert on memory approaching the limit before the kill happens.
The kernel terminated a container because it exceeded its memory limit. The container restarts without a graceful shutdown, which is why it appears to vanish.
Find why it reaches its limit: raise the limit if it is genuinely undersized, fix a memory leak if usage climbs steadily, or tune the workload if a spike drives it.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.