Chega de superprovisionar para a inicialização: conheça o novo CPU Startup Boost do GKE

O dilema: velocidade de inicialização vs. desperdício em idle

Toda equipe que roda workloads pesados e sensíveis à latência no Kubernetes é forçada a escolher entre duas concessões frustrantes:

Dimensionar para a inicialização e pagar por isso para sempre. Definir o CPU request alto o suficiente para passar rápido pela inicialização, mesmo que o app só precise de CPU mínima depois de aquecido. Esse request fica lá 24 horas por dia. É o que o scheduler usa para alocar o Pod, o que o cluster autoscaler usa para decidir se adiciona nós e o que aparece na sua fatura. Em algumas centenas de réplicas, o custo dessa troca entre inicialização mais rápida e desperdício contínuo se acumula rápido.

Dimensionar para o regime permanente e sofrer na inicialização. Definir o request de acordo com o uso real em runtime e aceitar que cada restart, cada rolling deployment, cada upgrade de nó significa uma espera longa até o Pod ficar pronto. Sob CPU throttling, um warm-up de JVM que deveria levar 5 segundos pode se estender para 30 ou mais. Isso significa rollouts mais lentos, scale-out mais lento durante eventos do HPA e possíveis picos de latência para os usuários.

Nenhuma das opções é realmente aceitável. O CPU startup boost foi criado para fechar essa lacuna.

O que o CPU startup boost realmente resolve

O CPU startup boost é um novo recurso do Vertical Pod Autoscaler (VPA) do GKE, atualmente em Preview. Ele permite aumentar temporariamente o CPU request de um container durante a inicialização do Pod e depois reduzi-lo automaticamente de volta ao baseline, sem reiniciar o container.

Runtimes que consomem muitos recursos (Java, Node.js e Python com imports pesados) recebem a folga de CPU de que precisam apenas quando precisam: durante a inicialização. Seu request de baseline pode refletir o uso real em regime permanente, em vez de um valor inflado para dar conta dos primeiros segundos de vida do Pod. Como a redução do valor com boost para o baseline usa o in-place Pod resize (IPPR) do Kubernetes, em vez de eviction e recriação do Pod, o container continua rodando o tempo todo.

Isso funciona em conjunto com a função habitual do VPA de recomendar e aplicar o dimensionamento de recursos de longo prazo. O startup boost é, na prática, apenas um override de curta duração aplicado por cima do baseline que o VPA (ou você) já estabeleceu.

Como funciona e como configurar

O passo a passo completo está aqui: Accelerate application startup with CPU startup boost.

O CPU startup boost é definido adicionando um bloco startupBoost ao seu objeto VerticalPodAutoscaler. Você pode aplicá-lo no nível do Pod, para que todos os containers recebam o mesmo boost, ou no nível do container, para direcionar containers específicos ou excluir alguns de um boost aplicado a todo o Pod.

Ele só é acionado na criação do Pod. Se um container reiniciar depois — por exemplo, após um OOMKill enquanto o Pod em si continua vivo —, o boost não é reaplicado. O admission webhook que injeta o boost roda apenas na admissão inicial do Pod.

O tipo de boost pode ser um multiplicador ou uma quantidade fixa. type: "Factor" multiplica o CPU request de baseline por um fator (factor: 2 o dobra); type: "Quantity" adiciona uma quantidade fixa de CPU por cima do baseline.

Ele funciona junto com os update modes do VPA, não no lugar deles. Use com updateMode: "Off" se quiser apenas o comportamento de boost e nada mais, ou combine com updateMode: "InPlaceOrRecreate" se também quiser que o VPA continue ajustando os recursos com base no uso contínuo.

Para configurar um boost no nível do Pod, use uma das opções a seguir.

Boost no nível do Pod, com atuação do VPA desligada

Use esta opção quando quiser o boost e nada mais — o VPA não aplicará nenhuma outra recomendação 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 container do Pod recebe 2x seu CPU request de baseline durante os primeiros 10 segundos após o Pod atingir Ready; depois disso, o GKE o redimensiona de volta in-place.

Boost no nível do Pod, com gerenciamento contínuo do VPA

Use esta opção quando quiser tanto o startup boost quanto o right-sizing contínuo e in-place dos recursos depois.

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

O comportamento do boost é o mesmo, mas updateMode: "InPlaceOrRecreate" significa que o VPA continua recomendando e aplicando mudanças de recursos ao longo da vida do Pod, tentando primeiro o resize in-place antes de recorrer à recriação.

Boost no nível do container, direcionado a um container

Útil quando um Deployment tem um sidecar ou container utilitário que não precisa do pico de CPU na inicialização. Você restringe o boost apenas ao container que precisa dele via 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"

Aqui, boosted-container-name recebe 2 vCPUs extras por cima do seu request de baseline durante a inicialização — uma quantidade fixa, e não um multiplicador.

Excluindo um container de um boost no nível do Pod

O caso inverso: um boost no nível do Pod está configurado, mas um container não deve receber o boost junto com o restante.

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

O boost no nível do Pod aplica um fator de 2x a tudo por padrão, mas a política do container sobrescreve isso com um fator de 1 para o container especificado.