`kubectl describe pod` shows `Last State: Terminated, Reason: OOMKilled, Exit Code: 137`, but the application's own logs have no stack trace, no exception, nothing. Why is there no Java-side evidence, and does the pod's QoS class have anything to do with why it was this pod that got killed?

OOMKilled is the kernel, not Java — the container's total memory usage hit the cgroup limit, and the kernel's OOM killer sent SIGKILL to the process, which ends it mid-instruction with no chance to log anything, because it was never given the chance to run any of its own error-handling code. That's a genuinely different event from a Java OutOfMemoryError, which is the JVM itself detecting it can't allocate more heap and throwing a catchable, loggable exception — different exit code (1, with a stack trace) from a completely different mechanism. QoS matters for which pod gets evicted under node-wide memory pressure (BestEffort first, then Burstable, Guaranteed last) — but a container hitting its own memory limit is a separate, per-container mechanism that fires regardless of QoS class or what else is happening on the node; a Guaranteed pod that exceeds its own limit is killed exactly as fast as a BestEffort one that does the same.