Cómo corregir políticas de recursos de Kubernetes que optimizan para la fase equivocada

TL;DR

• Una política de recursos de Kubernetes es cada capa que decide con qué requests y limits termina un contenedor: ResourceQuota, LimitRange, reglas de admisión (Kyverno, Gatekeeper, ValidatingAdmissionPolicy), los defaults de los charts de Helm y el recomendador que escribe los números.
• Cada una de esas capas asume un solo número por contenedor para toda su vida. Los contenedores tienen dos fases, arranque y estado estable, y la brecha entre ambas puede ser de 3x a 10x.
• Las políticas ajustadas al estado estable estrangulan y matan por OOM a los pods durante el arranque. Las políticas ajustadas al arranque reservan capacidad que nadie usa, llenan las cuotas del namespace con requests ociosos y dejan pods en Pending mientras el clúster está medio vacío.
• La solución es estructural: cuota sobre requests, no sobre limits; un LimitRange que permita el burst en lugar de recortarlo; reglas de admisión que exijan requests y limits de memoria pero dejen de imponer limits de CPU; y un recomendador que vea el arranque y el estado estable como números separados.
• El resize de pods in-place hace viable el último paso. El arranque recibe lo que necesita, luego el pod se reduce a su meseta sin reiniciarse, y la cuota se recupera en ese mismo instante.

En el artículo anterior vimos cómo detectar un pico de arranque: filtra las métricas de throttling y OOM por edad del contenedor, y el burst que los promedios esconden aparece en los primeros 60 segundos de vida de cada contenedor. Este artículo trata de qué hacer una vez que puedes verlo, porque lo difícil no es editar un Deployment. Lo difícil es que la capa de políticas alrededor de ese Deployment se escribió para una sola fase y seguirá empujando cada workload de vuelta hacia ella.

Solución 4: Dimensiona la memoria para el arranque y la CPU para el estado estable

Cuando la capa de políticas deja de forzar una única respuesta, la decisión por workload se simplifica, y es distinta para cada recurso.

El limit de memoria debe superar el pico de arranque. No existe la degradación elegante para la memoria. Si la inicialización asigna 900Mi y el limit es 768Mi, el contenedor muere con código de salida 137 antes de llegar siquiera a su meseta de 400Mi. Toma max_over_time(container_memory_working_set_bytes[5m]) sobre una ventana que incluya un rollout y fija el limit por encima de ese número con margen. Para workloads JVM, recuerda que el heap es solo una parte del panorama: el metaspace, la code cache y los stacks de los hilos quedan fuera de -Xmx.

El request de memoria se queda en la meseta. El request es lo que el scheduler reserva y lo que la cuota cuenta. Fijarlo en el working set de estado estable con un margen moderado mantiene el bin-packing fiel a la realidad. La brecha entre request y limit coloca al pod en QoS Burstable, lo que significa que es candidato a desalojo bajo presión de memoria del nodo antes que los pods Guaranteed. Para la mayoría de los servicios sin estado es un compromiso aceptable; para los que no, fija el request igual al limit de forma deliberada y acepta la reserva.

El request de CPU se queda en la meseta y el limit de CPU no existe. Sin cuota de CFS, el arranque toma prestados ciclos ociosos del nodo y los devuelve un minuto después. El request sigue importando: es lo que Karpenter y el scheduler usan para ubicar el pod, y lo que el HPA usa como divisor de la utilización. Dimensiónalo al p95 del estado estable, no al burst.

El único punto donde esto se rompe es un rollout que coloca muchos pods con picos en el mismo nodo recién creado a la vez. Sin CPU ociosa que tomar prestada, el arranque va lento por contención en lugar de por throttling. Acota maxSurge para que los pods nuevos lleguen en oleadas y no todos a la vez, y considera un topologySpreadConstraint sobre kubernetes.io/hostname para que los pods nuevos de un rollout no se apilen en un solo nodo. Un startupProbe con un failureThreshold dimensionado para el caso lento evita que el kubelet reinicie un pod que simplemente está arrancando bajo carga.

Solución 5: Deja que el recomendador vea dos fases y que el pod cambie de tamaño

Todo lo anterior evita que la política imponga el número equivocado. No produce el correcto. Para eso, el recomendador tiene que saber que el arranque y el estado estable son distintos, y el pod tiene que poder moverse entre ellos.

El Vertical Pod Autoscaler con su recomendador por defecto construye un histograma con decaimiento sobre aproximadamente ocho días de muestras. Un burst de 45 segundos es ruido para él, así que recomienda la meseta, y el siguiente rollout sufre throttling. Puedes restringirlo con minAllowed para que nunca baje de un piso que sobreviva el boot, pero eso solo vuelve a codificar el número de arranque como reserva permanente por otra puerta.

El resize de pods in-place cambia la forma del problema. Es estable desde Kubernetes 1.35, viene activado por defecto en 1.36, y permite cambiar los requests y limits de un contenedor en ejecución sin reinicio. El patrón es: arranca el pod con suficiente CPU y memoria para hacer el boot limpiamente, y luego redúcelo a los valores de estado estable cuando reporte que está listo. El startup CPU boost de GKE hace una versión de esto para Autopilot. El spec del pod solo necesita declarar que un cambio de CPU no debe provocar un reinicio:

containers:
- name: app
  resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: NotRequired   # o RestartContainer si el runtime no puede reducir el heap en vivo
  resources:
    requests:
      cpu: "2"          # valor de arranque; se redimensiona a ~200m tras el readiness
      memory: 1Gi
    limits:
      memory: 1Gi

Aquí es donde el trabajo de cuota de la Solución 1 da sus frutos. Un resize se valida contra la ResourceQuota como cualquier otro cambio de requests, así que cuando el pod se reduce de 2 núcleos a 200m, el namespace recupera 1.8 núcleos de cuota de inmediato. Cuarenta réplicas arrancan en oleadas, cada una conserva su reserva de arranque durante alrededor de un minuto, y la huella de estado estable del namespace se estabiliza en 8 núcleos en lugar de 80. Los pods dejan de quedarse en Pending detrás de reservas que describen una fase en la que ya nadie está.

Una restricción de diseño a tener en cuenta: un resize no puede cambiar la clase de QoS de un pod. Un pod que arrancó Burstable sigue siendo Burstable, y un pod Guaranteed debe mantener requests iguales a limits en cada resize. Es otra razón para no imponer Guaranteed por política a workloads que no lo necesitan.

Checklist para reescribir la política

1. Haz un inventario de las capas. Para cada namespace: kubectl get resourcequota,limitrange -o yaml, más cada regla de Kyverno/Gatekeeper/VAP que toque resources. Anota qué impone cada una.
2. Identifica la fase que asume cada capa. Cualquier limits.cpu en una cuota, cualquier max.cpu o maxLimitRequestRatio.cpu bajo en un LimitRange, y cualquier regla de admisión de "debe fijar limit de CPU" es una política de estado estable. Cualquier defaultRequest por encima de unos cientos de millicores, o cualquier mandato de requests iguales a limits, es una política de arranque.
3. Mide la brecha. Ejecuta la consulta de ratio entre requests y uso real por namespace. Cualquier valor por encima de 3 a 4 es cuota consumida por la fase equivocada.
4. Mueve la cuota a los requests. Quita limits.cpu de la ResourceQuota; conserva requests.* y limits.memory.
5. Abre el LimitRange. Elimina default.cpu, sube o elimina max.cpu, aplica maxLimitRequestRatio solo a memoria.
6. Reescribe la admisión. Exige requests de CPU y memoria y un limit de memoria. Deja de exigir un limit de CPU.
7. Redimensiona los diez workloads que más se reinician. Limit de memoria al pico de arranque, requests de memoria y CPU al p95 del estado estable, sin limit de CPU. Añade maxSurge y restricciones de distribución si los rollouts generan contención.
8. Habilita el dimensionamiento en dos fases donde el clúster lo soporte. En 1.33+ con resize in-place disponible, declara resizePolicy y deja que un controlador reduzca los pods después del readiness.
9. Repite el paso 3 una semana después. El ratio debería bajar hacia 1.5 a 2 y la tasa de throttling en contenedores jóvenes debería caer hacia cero al mismo tiempo. Si solo se movió uno, corregiste un recurso y no el otro.

Preguntas frecuentes

¿Qué es una resource quota de Kubernetes? Una ResourceQuota es un objeto con alcance de namespace que acota el total de recursos que todos los pods de ese namespace pueden solicitar o tener como límite, junto con conteos de objetos como pods, services y PVCs. Se aplica en la admisión: un pod cuyos requests o limits empujarían al namespace por encima de sus valores hard es rechazado. Las cuotas cuentan los números del spec del pod, no el uso real, y por eso una cuota puede agotarse mientras los nodos detrás de ella están ociosos.

¿Una ResourceQuota debería acotar limits o requests? Acota requests.cpu y requests.memory, porque los requests son lo que el scheduler reserva y lo que pagas en capacidad de nodos. Acota también limits.memory, ya que es una barrera de seguridad real contra un namespace que consuma toda la memoria del nodo. Evita limits.cpu en las cuotas: presiona a los equipos a reducir los limits de CPU para caber, lo que estrangula a los pods durante el arranque sin proteger el nodo.

¿Cuál es la diferencia entre ResourceQuota y LimitRange? ResourceQuota fija un total a nivel de namespace. LimitRange fija defaults, mínimos, máximos y el ratio permitido entre limit y request por contenedor (o por pod, o por PVC). La cuota responde "cuánto puede usar este equipo en total"; el LimitRange responde "qué recibe un contenedor si no lo especifica, y qué es lo máximo que puede pedir". Ambos se aplican en la admisión.

¿Los resize de pods in-place cuentan contra la ResourceQuota? Sí. Un resize que aumenta los requests se valida contra la cuota del namespace y se rechaza si la excedería. Un resize que reduce los requests devuelve la diferencia a la cuota de inmediato. Eso es lo que permite que un patrón de arrancar-y-reducir mantenga la huella de cuota de estado estable de un namespace cerca de su uso real.

¿Por qué mis pods sufren throttling en el arranque aunque el nodo tiene CPU ociosa? Porque un limit de CPU lo aplica la cuota de CFS del kernel por contenedor, independientemente de la carga del nodo. Si el limit es 500m, el contenedor recibe 50ms de cada período de 100ms sin importar cuán ocioso esté el nodo. El trabajo de arranque, como la compilación JIT o la carga de módulos, agota esa cuota al inicio de cada período y espera. Eliminar el limit de CPU, o subir maxLimitRequestRatio para que el limit pueda quedar muy por encima del request, permite que el arranque use la capacidad ociosa.

Políticas acordes a cómo se comportan realmente los contenedores

Todo lo anterior se puede hacer a mano: reescribir la cuota, abrir el LimitRange, actualizar la política de admisión, redimensionar los workloads más ruidosos y repetir cuando el código cambie. Lo difícil es esa última parte. Los perfiles de arranque cambian con cada actualización de dependencias y cada cambio de flag de la JVM, y una política que ajustaste correctamente en marzo vuelve a estar mal en junio.

PerfectScale by DoiT perfila cada contenedor a nivel de workload, así que el comportamiento de arranque y de estado estable aparece como patrones separados en lugar de un promedio mezclado, y sus recomendaciones dimensionan la memoria para superar el pico del boot mientras mantienen los requests en la meseta. Para workloads Java, detecta contenedores JVM automáticamente una vez habilitado el agente de Coroot, hace seguimiento del heap, el non-heap y el GC a lo largo del tiempo, marca los contenedores que corren sin configuración de heap explícita y respeta -Xms y -Xmx cuando propone 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, de modo que la cuota del namespace refleja lo que los workloads usan ahora y no lo que necesitaron durante 45 segundos después del último deploy.

¿Quieres ver un pod arrancar con 2 núcleos y estabilizarse en 200m sin reinicio y sin dejar cuota atrapada? Únete al taller sobre el pico de arranque de la JVM, o agenda una sesión técnica y revisaremos juntos las políticas de cuota y LimitRange de tus propios clústeres.