¿Conviene usar límites de CPU en Kubernetes en producción?
El hilo original planteaba dos cuestiones: si el consejo de "dejar de usar límites de CPU" sigue siendo válido y si utilizas límites de CPU en producción.
Sí, la mecánica sigue vigente. Que convenga o no usar límites depende de tu carga de trabajo y de la filosofía de tu clúster.
Qué hacen realmente los límites de CPU
En Kubernetes, una request de CPU orienta la planificación (scheduling), de modo que esa CPU queda garantizada en el momento de la asignación. Un límite de CPU es un tope estricto aplicado mediante cuotas CFS (el Completely Fair Scheduler de Linux). Cuando un contenedor alcanza su límite, sufre throttling.
Por qué se dice "deja de usar límites de CPU"
El artículo de Robusta describe un comportamiento real. Con límites configurados, los pods sufren throttling mientras el nodo tiene CPU ociosa, la latencia se dispara y el rendimiento se vuelve impredecible en los picos de tráfico.
La mecánica del kernel no ha cambiado, tal como confirma una de las respuestas:
"Sí, sigue siendo válido. La mecánica descrita no ha cambiado."
Para cargas con picos de actividad (bursty), que abarcan la mayoría de los servicios web, los límites perjudican más de lo que ayudan.
La realidad en producción
La respuesta no es "siempre" ni "nunca"; todo se reduce al objetivo buscado.
Caso 1: servicios web con picos de tráfico (la mayoría de las apps)
Las APIs, los frontends, los consumidores de eventos y las cargas típicas de SaaS suelen estar ociosos la mayor parte del tiempo con picos puntuales, y les conviene aprovechar la CPU que nadie está usando. Muchos clústeres los ejecutan con requests de CPU configuradas y sin límites de CPU.
La memoria es diferente. Casi siempre configuras límites de memoria, mientras que la CPU es elástica.
Caso 2: trabajos batch con uso intensivo de CPU
El procesamiento de datos, la codificación de vídeo, las cargas de ML y los ejecutores de CI/CD consumen CPU de forma constante, dejan sin recursos a sus vecinos y no obtienen ninguna ventaja de los picos. Aquí los límites sí justifican su presencia, y un participante comentó que los utiliza para cargas específicas o ejecutores de CI.
¿Qué pasa con la QoS?
Alguien preguntó:
¿alguna razón real para usar qos en producción?
Las clases de QoS cobran importancia cuando un nodo está bajo presión. Configurar request == limit otorga Guaranteed, indicar solo request da Burstable, y no definir ninguno deja el pod en BestEffort.
En la mayoría de los clústeres reales, Burstable funciona perfectamente bien, Guaranteed resulta útil para cargas críticas y BestEffort debería evitarse en producción. Aun así, la QoS no es motivo para añadir límites a ciegas, ya que influye mucho más en la expulsión por memoria que en el throttling de CPU.
El detalle engañoso: el throttling no es justicia distributiva
Los límites de CPU no "protegen" el clúster. Solo limitan al propio contenedor y no redistribuyen la CPU de manera equitativa entre las cargas como mucha gente imagina. Con un 30% de CPU en el clúster (el caso de un usuario), los límites no aportan nada salvo perjudicar potencialmente la respuesta ante picos.
Entonces, ¿qué hacen los equipos con experiencia?
Los patrones habituales de producción en 2026 se dividen en tres grupos.
Patrón A: SaaS moderno
Esta configuración es sumamente común hoy en día:
- Requests de CPU configuradas
- Sin límites de CPU
- Requests y límites de memoria definidos
- HPA basado en CPU o métricas
Patrón B: cargas de trabajo mixtas
Aquí los límites se aplican de forma selectiva. Los servicios web funcionan sin límites de CPU, mientras que los límites de CPU se reservan para:
- Trabajos batch
- Procesamiento de datos
- Ejecutores de CI
Patrón C: clústeres multi-tenant
Si varios equipos comparten un clúster y el nivel de confianza es bajo, los límites de CPU actúan como barreras de contención, combinados a menudo con ResourceQuota. Esa decisión responde más a una necesidad de gobernanza que de rendimiento.
Mi respuesta directa
¿Sigue siendo válido el consejo? Sí. ¿Utilizo límites de CPU? No para servicios de producción con picos de demanda, pero sí para tareas pesadas y prolongadas de CPU. Siempre configuro límites de memoria y siempre defino requests de CPU.
Donde los equipos se equivocan es al poner límites a todo sin comprender cómo funciona el throttling.