Un análisis técnico del repositorio k8s-cpu-limits-analyzed desmonta la práctica habitual de fijar límites (limits) de CPU en Kubernetes y demuestra, con pruebas empíricas, que esa configuración congela las aplicaciones hasta diez veces por segundo aunque el nodo disponga de CPU libre. Los autores ejecutan la misma aplicación con y sin límite, manteniendo idénticos el código, la solicitud (request) y la carga: el resultado es un aumento de 2,4 veces en la latencia de las peticiones lentas con una CPU media muy por debajo del tope, lo que evidencia que la latencia de cola se degrada aunque las gráficas de monitorización parezcan sanas.
El documento distingue con claridad los dos mecanismos de cgroup: la solicitud (cpu.weight) garantiza una parte proporcional del procesador mediante el planificador CFS, mientras que el límite (cpu.max) actúa como techo rígido evaluado en ventanas de 100 milisegundos. Cuando se agota el cupo, el kernel paraliza todos los hilos del proceso hasta la siguiente ventana, incluidas las hebras del recolector de basura en aplicaciones .NET o los consumidores de Kafka. Con 16 hilos activos y una cuota de 300m, el presupuesto se quema en menos de dos milisegundos de tiempo real.
El informe propone un plan de migración por fases: eliminar los límites de CPU, conservar las solicitudes como protección real y mantener los límites de memoria, ya que esta sí puede provocar el colapso del nodo. El modelo de costes incluido estima ahorros del orden de decenas de miles de dólares anuales por clúster al redimensionar correctamente las solicitudes una vez retirados los límites. El repositorio incluye documentación extendida, objeciones respondidas, datos brutos y casos específicos para .NET y PostgreSQL.