¿Cómo depuras un pod OOMKilled en Kubernetes?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

OOMKilled significa que el contenedor superó su límite de memoria y el kernel lo mató, así que lo primero es comprobar la razón de terminación y el límite en la especificación del pod, y luego la gráfica de memoria antes de cada reinicio para ver si el uso subió de forma constante, lo que sugiere una fuga, o en picos, lo que sugiere una ráfaga de trabajo o una asignación desproporcionada. Dentro de la aplicación, un perfil de heap o las métricas del runtime distinguen el heap del lenguaje de la memoria nativa, cachés y buffers; la JVM y el runtime de Go en particular necesitan sus propios límites alineados con los del contenedor. El arreglo es acotar el comportamiento, como el tamaño de una caché o de un lote, o fijar requests y límites a partir del uso medido con margen.

Ejemplo

Un pod Java con límite de 1 GiB moría cada pocas horas: la gráfica subía linealmente, el volcado de heap mostró una caché en memoria sin límite de objetos de sesión, y la JVM estaba configurada con un heap de 900 MiB más metaspace e hilos que en conjunto superaban el límite. Acotar la caché y fijar -XX:MaxRAMPercentage=70 detuvo las muertes sin subir el límite.

Errores frecuentes

• Duplicar el límite de memoria como primera y última respuesta.
• Ignorar la memoria nativa y los buffers fuera del heap cuando el heap parece bien.
• Poner un límite muy por encima del request, de modo que el nodo sobrecompromete y expulsa vecinos.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.