CPU throttling en Kubernetes: el 8% que nadie mide

Por qué el 92% de los equipos de infraestructura están midiendo la métrica equivocada

El 8% de utilización promedio de CPU es la cifra que reporta el State of Kubernetes 2026 de CAST AI, pero ese número esconde un problema crítico: contenedores con throttling severo que generan latencia p99 inaceptable mientras las gráficas de monitoreo muestran "todo verde". Si tu startup opera servicios sensibles a la latencia en Kubernetes o Docker, la métrica de utilización promedio de CPU te está dando una falsa sensación de seguridad.

Para un founder o CTO, esto se traduce en timeouts intermitentes, errores de "context deadline exceeded" y clientes frustrados sin que el equipo de ingeniería pueda diagnosticar la causa raíz. El problema no es tu código—es cómo estás midiendo la saturación real de tus contenedores.

¿Qué es el CPU throttling y por qué destruye tu latencia?

El throttling de CPU es un mecanismo del kernel Linux (CFS - Completely Fair Scheduler) que limita los ciclos de CPU disponibles para un contenedor cuando excede su cuota dentro de un periodo de control. Cuando esto ocurre, el contenedor queda pausado hasta el siguiente periodo, aunque la aplicación necesite procesar requests urgentes.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El patrón típico que observamos en producción:

Tu contenedor consume CPU rápidamente durante un pico de tráfico
Agota su cuota dentro del periodo CFS (usualmente 100ms)
El kernel lo pausa forzadamente
Los requests se encolan o timeoutean
La métrica de CPU promedio sigue mostrando 40-50% porque suaviza los picos

Empresas como Omio y Buk han documentado públicamente cómo el throttling agresivo en Kubernetes causó degradación de servicio intermitente que tardaron semanas en diagnosticar porque confiaban en métricas de utilización promedio.

¿Por qué la utilización promedio es engañosa en entornos de contenedores?

La utilización promedio de CPU tiene tres problemas fundamentales para servicios sensibles a la latencia:

1. Suaviza los picos de consumo. Un contenedor que alterna entre 100% de CPU (durante 50ms) y 0% (durante 50ms) mostrará 50% de utilización promedio, pero experimentará throttling severo durante la mitad de su tiempo de ejecución.

2. No revela si el contenedor fue penalizado por el scheduler. Puedes tener 30% de utilización promedio y aún así estar throttleado el 20% de los periodos de CFS—suficiente para degradar tu p95/p99 de latencia.

3. Oculta la forma temporal del consumo. Para el kernel, no es lo mismo consumir 1 core de forma sostenida que consumir 4 cores en ráfagas de 10ms. La métrica promedio las trata igual.

La documentación de Grafana Cloud es explícita: "Es común ver CPU throttling incluso cuando el uso de CPU parece bajo en las gráficas". Esto explica por qué tantos equipos de SRE reciben alertas de latencia sin entender la causa.

¿Qué métricas deberías usar en lugar de la utilización promedio?

Para detectar throttling real y saturación de CPU, necesitas medir señales que revelen contención, no sólo consumo. Estas son las métricas que los equipos de infraestructura maduros están adoptando en 2026:

Métricas de throttling del cgroup

Los contenedores exponen métricas críticas a través de cgroups que debes monitorear:

container_cpu_cfs_throttled_seconds_total: segundos totales que el contenedor estuvo throttleado
container_cpu_cfs_throttled_periods_total: número de periodos CFS donde ocurrió throttling
container_cpu_cfs_periods_total: número total de periodos CFS

Con estas métricas puedes calcular el ratio de periodos throttleados:

rate(container_cpu_cfs_throttled_periods_total[5m]) / rate(container_cpu_cfs_periods_total[5m])

Un ratio superior al 5-10% sostenido durante 15 minutos debería disparar una alerta, incluso si la utilización promedio parece normal.

cgroup cpu.stat: tu ventana al kernel

El archivo /sys/fs/cgroup/.../cpu.stat expone contadores directos del kernel:

nr_periods: cuántos periodos de cuota ocurrieron
nr_throttled: cuántos periodos fueron throttleados
throttled_time: tiempo total throttleado en nanosegundos

La relación nr_throttled / nr_periods te da el porcentaje de periodos afectados—una métrica mucho más honesta que la utilización promedio.

PSI (Pressure Stall Information): la métrica que el kernel quiere que uses

PSI es una característica del kernel Linux que mide tiempo que las tareas pasan esperando recursos, no consumo. Para CPU, PSI muestra:

some: al menos algunas tareas están demoradas por presión de CPU
full: todas las tareas relevantes están detenidas por presión de CPU

Puedes leer PSI en /proc/pressure/cpu. La ventaja clave: PSI detecta contención real, no sólo uso alto. Es especialmente útil para correlacionar picos de latencia con saturación del scheduler.

¿Qué significa esto para tu startup?

Si operas servicios en Kubernetes o Docker—especialmente si tienes SLOs estrictos de latencia—necesitas actuar sobre esta información. Aquí hay acciones concretas que puedes implementar esta semana:

Acción 1: Agrega métricas de throttling a tu dashboard de producción

No esperes a tener un incidente. Configura hoy mismo:

Un panel en Grafana que muestre container_cpu_cfs_throttled_seconds_total por pod crítico
Una alerta cuando el ratio de periodos throttleados supere el 10% durante 10 minutos
Correlación visual entre throttling y latencia p95/p99 de tu aplicación

Si usas Prometheus, esta query te da segundos throttleados por segundo por pod:

sum(rate(container_cpu_cfs_throttled_seconds_total{namespace="production", container!=""}[5m])) by (pod)

Acción 2: Revisa los CPU limits de tus servicios sensibles a la latencia

Para workloads con picos de tráfico o ráfagas de procesamiento (APIs web, servicios con GC, sistemas de colas):

Considera eliminar el CPU limit y mantener sólo el CPU request
Si debes mantener limits, hazlos 2-3x más altos que el consumo promedio observado
Usa HPA (Horizontal Pod Autoscaler) para escalar horizontalmente en lugar de restringir verticalmente

El trade-off: sin limits, un pod mal comportado puede consumir más CPU del nodo. Pero para servicios críticos, la predictibilidad de latencia vale más que el aislamiento perfecto.

Acción 3: Implementa PSI si tu kernel lo soporta

Linux 4.20+ incluye PSI. Si tus nodos lo soportan:

Exporta /proc/pressure/cpu a tu sistema de monitoreo
Configura alertas cuando some o full excedan umbrales por más de 5 minutos
Correlaciona PSI con throttling de cgroups para entender si el problema es del contenedor o del nodo

PSI es particularmente valioso en entornos multi-tenant donde la contención del nodo puede afectar tus pods incluso sin limits de CPU configurados.

Casos reales: qué aprendieron equipos de ingeniería en producción

Omio documentó cómo límites de CPU agresivos en Kubernetes causaron throttling que degradó sus servicios de manera intermitente. Su conclusión: para servicios latency-sensitive, los limits rígidos hacen más daño que beneficio.

Buk (Chile) publicó en su tech blog cómo el CPU throttling fue el "enemigo silencioso" que explicaba timeouts inexplicables en su plataforma de nómina. Su solución: monitoreo de cpu.stat y ajuste de limits basado en percentiles de consumo, no promedios.

Grafana Labs recomienda explícitamente tratar el throttling como una alerta operacional de primer nivel, no como una métrica de curiosidad. Su documentación señala que el throttling puede aparecer incluso con uso de CPU aparentemente bajo—exactamente el escenario que este artículo describe.

El costo oculto de confiar en métricas promedio

El reporte 2026 de CAST AI muestra que la utilización promedio de CPU en clusters Kubernetes cayó al 8%, mientras la memoria está en 20% y empeorando. Esto sugiere que los equipos están sobre-provisionando por miedo a throttling, o están configurando limits tan conservadores que desperdician recursos.

El equilibrio correcto:

Monitorea throttling, no sólo utilización
Ajusta limits basándote en percentiles (p95, p99) de consumo, no promedios
Prioriza la predictibilidad de latencia sobre la eficiencia de recursos para servicios críticos
Usa autoscaling horizontal para absorber picos en lugar de limits verticales rígidos

Para un founder, la pregunta no es "¿qué métrica es más precisa?" sino "¿cuántos incidentes de latencia podríamos haber prevenido si hubiéramos medido esto hace 6 meses?"

Conclusión

La utilización promedio de CPU es una métrica del siglo XX para problemas del siglo XXI. En entornos de contenedores con servicios sensibles a la latencia, el throttling de CFS puede destruir tu experiencia de usuario mientras tus dashboards muestran "todo normal".

Las alternativas existen y son accesibles: cgroup cpu.stat, PSI, y métricas de throttling de Prometheus te dan visibilidad real sobre la saturación de CPU. La pregunta es si tu equipo está dispuesto a cuestionar métricas establecidas y adoptar señales que el kernel Linux ha estado exponiendo durante años.

Para startups que escalan en Kubernetes, la diferencia entre un p99 aceptable y uno inaceptable puede estar en una sola métrica que nadie está mirando.