Deja de sobreaprovisionar por el arranque: llega el CPU startup boost de GKE

El dilema: velocidad de arranque vs. pérdida en reposo

Todo equipo que ejecuta workloads pesados y sensibles a la latencia en Kubernetes se ve obligado a elegir entre dos concesiones frustrantes:

Dimensionar para el arranque y pagarlo para siempre. Define un CPU request lo suficientemente alto para superar la inicialización rápidamente, aunque la app solo necesite un mínimo de CPU una vez caliente. Ese request queda ahí las 24 horas. Es lo que el scheduler usa para ubicar el Pod, lo que el cluster autoscaler usa para decidir si agregar nodos y lo que se te factura. Con unos cientos de réplicas, el costo de ese arranque más rápido —una pérdida constante— se acumula rápido.

Dimensionar para el estado estable y sufrir en cada arranque. Ajusta el request al uso real en ejecución y acepta que cada reinicio, cada rolling deployment y cada actualización de nodo implique avanzar a paso de tortuga hasta estar listo. Con throttling de CPU, un warm-up de JVM que debería tomar 5 segundos puede estirarse a 30 o más. Eso significa despliegues más lentos, escalado horizontal más lento durante eventos del HPA y posibles picos de latencia para los usuarios.

Ninguna de las dos opciones es realmente aceptable. CPU startup boost nació para cerrar esa brecha.

Qué resuelve realmente el CPU startup boost

CPU startup boost es una nueva capacidad del Vertical Pod Autoscaler (VPA) de GKE, actualmente en Preview. Permite aumentar temporalmente el CPU request de un contenedor durante la inicialización del Pod y luego reducirlo automáticamente al valor base sin reiniciar el contenedor.

Los runtimes con alto consumo de recursos (Java, Node.js y Python con imports pesados) obtienen el margen de CPU que necesitan solo cuando lo necesitan: durante la inicialización. Tu request base puede reflejar el uso real en estado estable, en lugar de un valor inflado para cubrir los primeros segundos de vida del Pod. Como la reducción del valor con boost al valor base usa el in-place Pod resize (IPPR) de Kubernetes en lugar de expulsar y recrear el Pod, el contenedor sigue ejecutándose todo el tiempo.

Esto funciona en paralelo con la tarea habitual de VPA: recomendar y aplicar el dimensionamiento de recursos a largo plazo. El startup boost es, en realidad, solo un ajuste puntual y de corta duración que se aplica sobre el valor base que VPA (o tú) ya haya establecido.

Cómo funciona y cómo configurarlo

Aquí tienes la guía completa: Accelerate application startup with CPU startup boost.

El CPU startup boost se define agregando un bloque startupBoost a tu objeto VerticalPodAutoscaler. Puedes aplicarlo a nivel de Pod, para que todos los contenedores reciban el mismo boost, o a nivel de contenedor, para dirigirlo a contenedores específicos o excluir algunos de un boost aplicado a todo el Pod.

Solo se activa en la creación del Pod. Si un contenedor se reinicia más tarde —por ejemplo, tras un OOMKill mientras el Pod sigue vivo—, el boost no se vuelve a aplicar. El admission webhook que inyecta el boost solo se ejecuta en la admisión inicial del Pod.

El tipo de boost puede ser un multiplicador o una cantidad fija. type: "Factor" escala el CPU request base con un multiplicador (factor: 2 lo duplica); type: "Quantity" agrega una cantidad fija de CPU sobre el valor base.

Funciona junto con los update modes de VPA, no en su lugar. Ejecútalo con updateMode: "Off" si solo quieres el comportamiento del boost y nada más, o combínalo con updateMode: "InPlaceOrRecreate" si además quieres que VPA siga ajustando los recursos según el uso continuo.

Para configurar un boost a nivel de Pod, usa una de las siguientes opciones.

Boost a nivel de Pod, con actuación de VPA desactivada

Usa esta opción cuando quieras el boost y nada más: VPA no aplicará ninguna otra recomendación de recursos.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Cada contenedor del Pod recibe el doble de su CPU request base durante los primeros 10 segundos después de que el Pod alcanza el estado Ready; luego, GKE lo reduce de nuevo in-place.

Boost a nivel de Pod, con gestión continua de VPA

Usa esta opción cuando quieras tanto el startup boost como un right-sizing continuo de recursos in-place después del arranque.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

El mismo comportamiento de boost, pero con updateMode: "InPlaceOrRecreate" VPA sigue recomendando y aplicando cambios de recursos durante toda la vida del Pod, intentando primero redimensionar in-place antes de recurrir a la recreación.

Boost a nivel de contenedor, dirigido a un solo contenedor

Es útil cuando un Deployment tiene un sidecar o un contenedor utilitario que no necesita el pico de CPU en el arranque. El boost se limita solo al contenedor que lo necesita mediante resourcePolicy.containerPolicies.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Aquí, boosted-container-name recibe 2 vCPUs adicionales sobre su request base durante el arranque: una cantidad fija en lugar de un multiplicador.

Excluir un contenedor de un boost a nivel de Pod

El caso inverso: hay un boost definido a nivel de Pod, pero uno de los contenedores no debe recibirlo junto con el resto.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

El boost a nivel de Pod aplica por defecto un factor de 2x a todos los contenedores, pero la política del contenedor lo anula con un factor de 1 para el contenedor indicado.