How do you debug a Kubernetes OOMKilled pod?

Direct answer

What a strong answer covers

How it works

OOMKilled means the container exceeded its memory limit and the kernel killed it, so the first check is the termination reason and the limit in the pod spec, then the memory graph before each restart to see whether usage climbed steadily, which suggests a leak, or spiked, which suggests a burst of work or an oversized allocation. Inside the application, a heap profile or runtime metrics distinguish the language heap from native memory, caches, and buffers; the JVM and Go runtimes in particular need their own limits aligned with the container’s. The fix is either bounding the behaviour, such as a cache size or a batch size, or setting requests and limits from measured usage with headroom.

Example

A Java pod with a 1 GiB limit was killed every few hours: the graph climbed linearly, the heap dump showed an unbounded in-memory cache of session objects, and the JVM was configured with a 900 MiB heap plus metaspace and threads that together exceeded the limit. Bounding the cache and setting -XX:MaxRAMPercentage=70 stopped the kills without raising the limit.

Common mistakes

• Doubling the memory limit as the first and last response.
• Ignoring native memory and off-heap buffers when the heap looks fine.
• Setting a limit far above the request so the node overcommits and evicts neighbours.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.