Requests altos de Kubernetes pagan nodos vacíos

La factura cloud de un clúster de Kubernetes sigue los recursos reservados, porque el scheduler y el autoscaler de nodos operan sobre los requests. Los limits, los presupuestos de namespace y el autoscaling solo actúan si están ligados a esa reserva. Quien mantiene los requests altos paga capacidad reservada.

Lo esencial en breve

Relacionado:La observabilidad se come el presupuesto cloud sin aviso  /  EKS 1.36 se encarece si falta disciplina FinOps

¿Qué son los requests de Kubernetes? Kubernetes trata los requests de CPU y memoria como reserva para la colocación. El scheduler asigna el pod solo a un nodo que aún tenga libre esa cantidad. El Cluster Autoscaler cuenta la misma cifra al decidir si hace falta un nodo nuevo. Quien mantiene los requests altos paga capacidad reservada. Los limits acotan el consumo en tiempo de ejecución.

Por qué los requests fijan el número de nodos

Kubernetes trata los requests de CPU y memoria como reserva para la colocación. El scheduler suma los requests de los pods ya en marcha en un nodo y solo acepta un pod nuevo si el resto, según el request, basta. El uso medido no interviene en este paso. Un servicio con poca carga y un request grande bloquea la misma capacidad que un servicio que sí agota la reserva. Los servicios de sistema y los DaemonSets restan de esa suma del nodo antes de que los pods de aplicación encuentren sitio.

El autoscaler de nodos observa pods que siguen en Pending porque en ningún sitio queda libre suficiente capacidad de request. Entonces surge un nodo adicional y, con él, otra instancia en la factura cloud. Si los requests crecen en muchos namespaces y réplicas, la flota crece aunque el tráfico esté plano. La facturación de los grandes proveedores depende de las instancias en marcha, de los Persistent Volumes y de la red. Tras una prueba de carga, esos nodos siguen en pie si nadie rebaja los requests o el número de réplicas.

Los requests determinan así cuánta capacidad mantiene reservada de hecho la plataforma. Quien los mantiene altos paga capacidad reservada. Quien los deja demasiado justos genera Pending, desalojo bajo presión y un scale-up que puede quedarse tras el pico. Una plataforma que solo comenta facturas y no toca las specs no tiene el mando. La fragmentación lo agrava, porque unos pocos pods grandes dejan capacidad residual que no alcanza para otros requests.

Muchos modelos internos de reparto imputan el coste de los nodos según los requests. Es coherente, porque justo esos campos impulsan el empaquetado y, a menudo, el número de nodos. Sin requests fiables, cada conversación de presupuesto se vuelve una estimación. El equipo discute entonces porcentajes de reparto mientras la flota sigue creciendo sin que se note. De ahí el primer control: si la spec recoge lo que de verdad ata los nodos.

Los limits contienen el daño en ejecución

Los limits cortan la CPU y la memoria en cuanto un contenedor supera el tope. En la CPU aparece throttling, visible en la latencia de cola de las peticiones. En memoria, el pico suele acabar en un OOMKill. Ambas cosas protegen las cargas vecinas del mismo nodo y acotan el radio de impacto local. Ninguna cambia la factura mientras los requests sigan igual y los nodos sigan en marcha.

La clase de Quality of Service se deriva del request y del limit. Si ambos están definidos y son iguales, rige Guaranteed. Si el request es menor que el limit, rige Burstable. Si faltan los dos, el pod cae en BestEffort y, ante escasez, es el primero en ser desalojado. Los equipos suelen igualar request y limit para forzar Guaranteed, con lo que el request sube con el limit y baja la densidad de empaquetado.

Un limit sin un request sólido invierte el problema. El scheduler empaqueta apretado y, en ejecución, el contenedor puede ir muy por encima de la reserva. Bajo carga aparecen CPU steal y presión de memoria en los vecinos. Coste y estabilidad se tuercen a la vez, porque el nodo está más lleno de lo que asumió la lógica de empaquetado. Los limits son un freno operativo.

El rightsizing exige uso más colchón

El rightsizing fija los requests en la carga observada más un colchón elegido a propósito. Hacen falta series de uso de días y semanas, porque un pico aislado de una ventana de despliegue no sirve de medida. Quien solo mide el mediodía laborable infravalora el batch nocturno. Quien solo mide la ventana de despliegue sobrevalora el régimen continuo. CPU y memoria siguen patrones de fallo distintos, porque la CPU se puede estrangular y la memoria no.

Los autoscalers verticales pueden proponer o fijar requests. Acortan el bucle manual y trasladan la responsabilidad a la ventana de observación, los mínimos y la estabilidad. Ventanas demasiado cortas generan oscilación entre clases de tamaño. Cada cambio de request altera el empaquetado y puede quitar o añadir nodos. Un rightsizing que no tenga en cuenta el autoscaler de nodos queda incompleto, porque el ahorro solo nace cuando las instancias desaparecen de verdad.

El colchón forma parte del diseño. Los jobs batch, los heaps, las cachés y los picos de arranque necesitan holgura, y esa holgura tiene que estar en los requests. La regla debe estar nombrada, por ejemplo frente a un percentil alto de uso, y revisarse de forma periódica. Si no, la reserva se queda fija como sobreaprovisionamiento injustificado. Una reserva que ya nadie sabe explicar es, en la práctica, un segundo presupuesto oculto.

Clases de servicio distintas no admiten una fórmula única. Los frontends sin estado, los workers de colas y los runtimes intensivos en memoria tienen perfiles distintos. La revisión se hace por clase de servicio y según su perfil de carga. Un recorte global en todos los namespaces produce de forma sistemática throttling en un sitio y nodos vacíos en otro.

Los presupuestos de namespace frenan el crecimiento silencioso

Sin tope, la suma de requests crece con cada despliegue, cada sidecar y cada réplica. Las ResourceQuotas sobre requests de CPU y memoria limitan lo que un namespace puede reservar en total. Los LimitRanges fijan valores por defecto, mínimos y máximos por contenedor. Así surgen menos pods sin request. La falta de valores por defecto es una fuente habitual de reserva silenciosa, porque más tarde se amplía a posteriori un servicio que parecía pequeño.

Un presupuesto que solo topa limits deja seguir la reserva. Un presupuesto solo sobre el número de pods ignora specs hinchadas. La quota debe actuar sobre lo que ata nodos: CPU de request, memoria de request, PersistentVolumeClaims y, si hace falta, el número de cargas. Cómo lo refleja luego cada proveedor en la factura varía.

Las quotas sin proceso se sortean. Namespaces nuevos, un segundo clúster y requests en namespaces de sistema compartidos eluden el tope. Las subidas pertenecen a la misma revisión que una ampliación de capacidad. Un equipo que quiere más reserva tiene que mostrar uso y eventos de limit. Si no, la plataforma financia esperanza sin datos.

Presupuestos separados para producción y no producción evitan que las pruebas de carga se coman la reserva productiva. Un clúster compartido sin quotas separadas convierte eso en la sorpresa habitual. La plataforma debe mostrar qué parte de una quota ya está ligada por requests. Sin esa visibilidad, el rechazo de un despliegue llega por sorpresa y el equipo busca un rodeo al tope.

El autoscaling amplifica cada error de la spec

El Horizontal Pod Autoscaler cambia el número de réplicas según CPU, memoria o métricas personalizadas. La utilización relativa de CPU depende del request y, con ello, de la reserva elegida. Cada réplica aporta sus requests enteros al empaquetado. Si el request es demasiado alto, surgen copias caras y antes hace falta un nodo. Si el request es demasiado bajo, la utilización parece alta y el autoscaler escala pronto, mientras el scheduler empaqueta mal unos pods dimensionados con demasiado poco margen.

Escalar en vertical y en horizontal sin un responsable claro genera oscilaciones. La vía vertical cambia el tamaño; la horizontal, el número. El autoscaler de nodos responde con instancias. En la transición suelen convivir tamaños viejos y nuevos. Justo ahí suben a la vez el coste y las colas de Pending, a menudo junto con throttling, porque el tamaño nuevo aún no es estable.

Los límites de escalado tienen que encajar con las quotas del namespace. Un máximo alto con una quota estrecha produce Pending en lugar de capacidad. Una quota amplia sin máximo produce crecimiento de nodos. La cadena sigue fija: primero el tamaño del request, luego el número de réplicas, después el tope del namespace y, al final, el número de nodos. Quien se salta un escalón ve el efecto solo en la factura.

Las ventanas de estabilización entran en la misma revisión. Ventanas demasiado cortas generan flapping y cambios constantes de empaquetado. Ventanas demasiado largas retienen, tras el pico, nodos que ya nadie necesita. El autoscaling multiplica la spec que ya está en el fichero.

Qué tres indicadores cuentan cada semana

Para el corte semanal de costes basta un conjunto corto que una la operación con la factura. Primero, la utilización de requests: uso medido de CPU y memoria respecto al request, separado por carga y namespace, agregado a la semana. Si se mantiene muy baja, la reserva está hinchada. Si se mantiene cerca de la reserva completa, falta colchón o el request es demasiado justo. CPU y memoria se leen por separado, porque piden correcciones distintas.

Segundo, la capacidad de request sin usar en el clúster. Es el delta entre capacidad reservada, capacidad empaquetable y carga medida. Se ve como nodos poco utilizados, como un grado de empaquetado bajo o como namespaces con mucha reserva y poco uso. Esa magnitud explica por qué la factura no baja con el tráfico. Da al equipo de aplicación y a la plataforma una cifra común.

Tercero, los eventos de limit: tiempo de throttling de CPU y OOMKills por carga. Si suben tras un rightsizing, el colchón fue demasiado agresivo. Si siguen altos con una utilización de request baja, request y limit están mal ajustados entre sí. Un control de costes que solo baja la factura e ignora estos eventos traslada el daño al incidente. El throttling se ve como latencia en el recorrido del usuario. Tres indicadores, un ritmo semanal fijo.

Quien puede cambiar la spec controla la factura

La mecánica solo funciona si está claro quién puede cambiar requests, limits y quotas. Los equipos de aplicación necesitan margen en su namespace. La plataforma necesita veto en cuanto la suma de requests obliga a crear nodos. Un portal de autoservicio sin vínculo con la quota convierte cada escalado en un pedido a cargo de la plataforma.

Los cambios de requests van por el mismo camino visible que otras specs con efecto en producción. Un cambio que duplica los requests de CPU es una decisión de capacidad. Debe llevar series de uso y los tres indicadores semanales. Si no, un valor por defecto sacado de un tutorial sigue meses en producción y ocupa capacidad que ya nadie justifica.

La factura sigue dependiendo de las instancias. Quien revisa cada semana requests, limits y el tope del namespace con los mismos tres indicadores mantiene el número de nodos y la propagación del daño en una sola revisión. Quien lo aplaza al ticket posterior al mes de facturación llega tarde.

Preguntas frecuentes

Fuente de la imagen: generada por IA (septiembre de 2026)

Traducido del original en alemán con inteligencia artificial. La versión alemana es la de referencia.