CPU Throttling y OOM Kills en Kubernetes: detecta los picos de arranque

TL;DR

• Un pico de arranque es la ráfaga de CPU y memoria que necesita un contenedor durante la inicialización (carga de clases, compilación JIT, carga de dependencias, calentamiento de cachés, pools de conexiones) y que desaparece cuando el proceso alcanza el estado estable.
• Los promedios, e incluso el p99 de una semana, lo ocultan. Una ráfaga de 45 segundos dentro de una ventana de 7 días representa menos del 0.01% de las muestras, así que cualquier recomendación basada en el uso combinado dimensiona el pod para la fase equivocada.
• El pico se manifiesta como CPU throttling, OOM kills con código de salida 137, readiness probes fallidas y rollouts lentos que se concentran en el primer minuto de vida del contenedor y luego desaparecen.
• Detéctalo graficando el uso contra la edad del contenedor en lugar del tiempo de reloj, y filtrando las métricas de throttling y OOM a contenedores jóvenes.
• Cuando se pueden ver las dos fases por separado, puedes dimensionar cada una en lugar de elegir qué incidente prefieres.

Tu servicio funciona bien. La CPU está al 15% de su límite, la memoria al 60%, sin alertas. Entonces un rollout reemplaza 40 pods, la mitad sufre throttling durante 50 segundos, tres reciben un OOM kill en el primer arranque, las readiness probes fallan y el rollout se estanca. Diez minutos después todo vuelve a verse saludable y los dashboards no muestran nada fuera de lo común.

Eso es un pico de arranque, y se esconde porque todas las métricas que usas para dimensionar workloads lo promedian hasta hacerlo desaparecer.

Una checklist de detección que puedes correr esta semana

1. Elige los workloads que más se reinician. Consulta increase(kube_pod_container_status_restarts_total[7d]) y ordena de forma descendente. Los picos de arranque golpean más fuerte donde más arranques hay.
2. Verifica si el throttling depende de la edad. Ejecuta la consulta de throttling en contenedores jóvenes de arriba contra los mismos workloads con más de diez minutos de vida. Una brecha grande confirma el pico.
3. Revisa el patrón de OOM. Para cualquier workload con OOMKilled en last_terminated_reason, mira restarts_total. Conteos bajos agrupados después de los deploys significan OOM de arranque.
4. Mide el tiempo hasta ready a lo largo de un rollout. Lanza un rollout en staging, registra el histograma de readiness, luego reduce el límite de CPU a la mitad y repite. El delta es el costo de tu pico en segundos.
5. Mira los primeros 300 segundos de un pod. Un panel de Grafana, un pod, uso contra límite. Si la línea se aplana contra el límite, anota cuánto dura.
6. Separa los dos números. Para cada workload con picos, registra el máximo de arranque y el p95 en estado estable. La proporción entre ambos te dice cuánto pagas de más si dimensionas para el pico, y cuánto throttling sufres si dimensionas para la meseta.

Las soluciones que lo empeoran sin que lo notes

Algunas respuestas comunes esconden el síntoma en lugar de resolverlo.

Agregar un startupProbe con un failureThreshold generoso detiene el bucle de reinicios, lo cual es la decisión correcta en términos de confiabilidad, pero también apaga la alerta. El pod sigue arrancando con throttling durante 90 segundos y los usuarios siguen esperándolo; solo que dejas de verlo.

Subir el request de CPU para cubrir el pico arregla el throttling y fija esa pérdida en cada réplica por el resto de su vida. En un servicio de 40 réplicas con un pico de 2 núcleos y una meseta de 200m, esa decisión reserva 72 núcleos que permanecen inactivos el 99.9% del tiempo. También perjudica el bin-packing, ya que el scheduler ubica los pods según el request, y los requests inflados significan menos pods por nodo y más nodos de los que necesitas.

Eliminar los límites de CPU por completo, lo que PerfectScale recomienda para la mayoría de los workloads en la guía de límites de CPU, sí permite que el arranque aproveche la capacidad inactiva del nodo. Ayuda, y suele ser el default correcto. Pero solo funciona cuando el nodo tiene CPU inactiva en el momento en que el pod arranca. Durante un rollout, cuando 20 pods nuevos caen en el mismo nodo recién creado y todos empiezan a compilar a la vez, no hay CPU inactiva que aprovechar. El pico regresa en forma de contención en lugar de throttling.

Cada una de estas es una jugada razonable por sí sola. El problema es que las tres siguen tratando al contenedor como un solo número cuando su uso tiene dos formas distintas.

Dimensionar para dos fases en lugar de una

Kubernetes ya tiene la primitiva que hace posible un enfoque de dos fases. El resize de pods in-place, que permite cambiar los requests y límites de un contenedor en ejecución sin reiniciarlo, se volvió estable en 1.35 y viene activado por defecto en 1.36 (PerfectScale probó la alpha allá por 2024, con bugs incluidos). GKE ya lo usa para su función de startup CPU boost. El patrón es simple: dale al pod lo que necesita para arrancar y quítaselo cuando alcance el estado estable.

Eso solo funciona si puedes distinguir las dos fases desde el principio, que es justo para lo que sirve todo lo anterior.

Preguntas frecuentes

¿Qué es el CPU throttling en Kubernetes? El CPU throttling ocurre cuando un contenedor intenta usar más tiempo de CPU del que su límite permite dentro de un período de scheduling de CFS (100ms por defecto). El kernel pausa el contenedor hasta que empieza el siguiente período. Un límite de 500m deja que un contenedor corra 50ms de cada 100ms; si lo agota temprano, el contenedor espera. El throttling ralentiza la aplicación sin tumbarla, y puede ocurrir incluso cuando el nodo tiene CPU inactiva.

¿Por qué mi pod recibe un OOM kill solo durante el arranque? La inicialización suele asignar más memoria que la operación en estado estable: cargar clases, construir cachés, correr migraciones o dimensionar un heap de JVM antes de que la aplicación conozca su working set real. Si el límite de memoria cubre el número del estado estable pero no el pico de arranque, el kernel mata el contenedor durante el boot con código de salida 137. Una vez que sobrevive al arranque, el uso cae por debajo del límite y el pod funciona con normalidad; por eso el contador de reinicios suele detenerse en uno o dos.

¿Cómo distingo un pico de arranque de un problema de dimensionamiento en estado estable? Filtra tus métricas de throttling y OOM por edad del contenedor. Si los problemas se concentran en los primeros uno o dos minutos de vida del contenedor y desaparecen después, es un pico de arranque. Si ocurren en puntos aleatorios a lo largo de la vida del pod, el request o el límite de estado estable está mal.

¿Eliminar los límites de CPU soluciona el throttling de arranque? Elimina la cuota de CFS, así que el contenedor puede aprovechar la CPU inactiva que tenga el nodo. Eso ayuda cuando los nodos tienen margen. No ayuda durante un rollout en el que muchos pods arrancan en el mismo nodo al mismo tiempo, porque no hay CPU inactiva que aprovechar. El request sigue determinando el scheduling, así que un request subdimensionado puede seguir colocando demasiados pods con picos en un mismo nodo.

Ver las dos fases de cada workload

Todo lo anterior lo puedes construir a mano con Prometheus, kube-state-metrics y unos cuantos paneles de Grafana. Lo difícil es hacerlo para 400 workloads y mantenerlo al día mientras los cambios de código mueven el pico de lugar.

PerfectScale by DoiT perfila cada contenedor a nivel de workload, de modo que el comportamiento de arranque y el de estado estable aparecen como patrones separados en lugar de un promedio mezclado. Para los workloads de Java profundiza una capa más: con el agente de Coroot habilitado, detecta automáticamente los contenedores con JVM y rastrea el heap, el non-heap y el tiempo de GC a lo largo del tiempo, marca los contenedores que corren sin configuración explícita del heap, y respeta -Xms y -Xmx cuando propone una recomendación o aplica un cambio. En clústeres con Kubernetes 1.33 o posterior, su automatización aplica el right-sizing in-place, sin reiniciar el pod, y recurre a un rolling restart solo cuando un resize no es viable en el nodo actual.

¿Quieres ver en vivo cómo se aplana el pico de arranque? Únete al workshop sobre el pico de arranque de la JVM, donde recorremos lo que pasa dentro de la JVM durante el boot y redimensionamos un pod en ejecución hasta su estado estable sin reinicios. O agenda una sesión técnica y revisamos tus clústeres juntos.