Estratégias para reduzir a latência de inicialização

O Google Kubernetes Engine (GKE) oferece várias estratégias que ajudam a reduzir a latência de inicialização de pods quando as cargas de trabalho escalonar verticalmente. Ao reduzir os atrasos no provisionamento de nós, na extração de imagens de contêiner e na inicialização de aplicativos, você pode melhorar a capacidade de resposta do serviço durante picos de tráfego e equilibrar os custos de infraestrutura.

Use este documento para comparar as estratégias de redução de latência de inicialização do GKE no ciclo de vida de inicialização de pods e escolher uma única estratégia ou uma combinação em camadas que atenda aos requisitos da carga de trabalho.

Entender o ciclo de vida de inicialização de pods

Quando uma carga de trabalho é escalonada no GKE e os nós atuais não têm capacidade alocável suficiente para os novos pods, a latência de inicialização de ponta a ponta abrange três etapas sequenciais:

  • Durante a etapa de provisionamento de nós e programação de pods, o escalonador automático de clusters provisiona uma nova VM do Compute Engine, inicializa o nó e o registra no plano de controle para que o programador do Kubernetes possa colocar o pod pendente.
  • Durante a etapa de extração de imagens do contêiner, o componente kubelet no nó faz o download e descompacta as imagens do contêiner necessárias para o pod do Container Registry.
  • Durante a etapa de inicialização do aplicativo, o ambiente de execução do contêiner inicia o processo do aplicativo, carrega dependências ou pesos do modelo na memória e transmite as verificações de inicialização e prontidão do Kubernetes.

Diferentes recursos do GKE têm como destino etapas específicas desse ciclo de vida. Para saber qual etapa contribui mais para o tempo de inicialização da carga de trabalho, consulte Monitorar métricas de latência de inicialização.

Comparar estratégias de redução de latência de inicialização

A tabela a seguir compara as estratégias de redução de latência de inicialização do GKE no ciclo de vida de inicialização de pods:

Estratégia Etapa do ciclo de vida Perfil de latência Perfil de custo e cota Modo de cluster e suporte de hardware Ideal para
Buffers de capacidade ativa (prévia pública) Provisionamento de nós e programação de pods Programação imediata de pods porque os nós já estão em execução.

Taxas de computação padrão baseadas em nós para VMs em execução.

Consome cotas de vCPU, memória, disco e endereço IP do Compute Engine cotas, além de cotas de recursos do Kubernetes no namespace.

Clusters padrão e clusters do Autopilot com ComputeClasses personalizadas (faturamento baseado em nós).

Oferece suporte a CPUs, GPUs e TPUs.

 Absorver picos de tráfego repentinos e escalonar cargas de trabalho de GPU, TPU ou CPU sensíveis à latência.
Buffers de capacidade de espera (prévia pública) Provisionamento de nós e programação de pods Retoma nós suspensos em aproximadamente 30 a 35 segundos, o que é mais rápido do que provisionar um novo nó.

Sem cobranças de computação de VM durante a suspensão. Incorrer em cobranças de armazenamento do Persistent Disk para discos de inicialização e estado de memória armazenado.

Consome cotas de disco e endereço IP durante a suspensão, além de cotas de recursos do Kubernetes no namespace.

Clusters padrão (com provisionamento automático de nós) e clusters do Autopilot com ComputeClasses personalizadas.

Oferece suporte apenas a CPUs (sem GPUs, TPUs ou SSDs locais).

 Manter a capacidade de burst econômica para o crescimento sustentado do tráfego growth.
Nós de inicialização rápida Provisionamento de nós e programação de pods Reduz o tempo de inicialização de nós frios da melhor maneira possível usando hardware pré-inicializado. Fornecido sem custo financeiro adicional.

Clusters do Autopilot e cargas de trabalho do Autopilot em clusters padrão.

Oferece suporte a séries de máquinas de uso geral e de GPU qualificadas sem SSDs locais ou VMs spot.

 Acelerar o provisionamento de nós de referência sem configuração ou custo de capacidade ociosa.
Pods de marcador de posição de baixa prioridade Provisionamento de nós e programação de pods Programação imediata de pods após a remoção de pods de marcador de posição de baixa prioridade pods.

Taxas de computação padrão para nós em execução.

Requer gerenciamento manual de implantação e PriorityClass.

 Clusters padrão e do Autopilot. Reservar capacidade extra em clusters que usam faturamento baseado em pods ou versões anteriores à 1.35.
Streaming de imagens Extração de imagem do contêiner Permite que os contêineres sejam iniciados sem esperar o download da imagem inteira.

Fornecido sem custo financeiro adicional.

Requer repositórios do Artifact Registry ou do Docker Hub qualificados.

 Clusters do Autopilot (ativado por padrão) e padrão clusters. Reduzir os tempos de extração de imagens para imagens de contêiner grandes.
Discos de inicialização secundários Extração de imagem do contêiner Anexa um Persistent Disk pré-preenchido a novos nós em paralelo com o provisionamento de nós. Cobrança pelo Persistent Disk anexado em cada nó e armazenamento de imagem do disco. Clusters padrão e do Autopilot. Pré-carregar imagens de contêiner grandes ou conjuntos de dados estáticos, como pesos de modelos de machine learning.
Snapshots de pods Inicialização do aplicativo Restaura novas réplicas de pods diretamente de um checkpoint salvo da memória do processo e do estado do sistema de arquivos. Cobrança pelo armazenamento de snapshots no Cloud Storage.

Clusters padrão e do Autopilot que executam pods no GKE Sandbox.

Oferece suporte a tipos de máquinas de CPU e GPU qualificados (sem TPUs).

 Ignorar a inicialização longa para modelos de inferência de IA e aplicativos com rotinas de inicialização pesadas.
Otimização da CPU de inicialização (prévia pública) Inicialização do aplicativo Aumenta temporariamente as solicitações e os limites da CPU durante a inicialização do pod e , em seguida, os redimensiona no local. Consome temporariamente a capacidade extra da CPU do nó durante a janela de inicialização. Clusters padrão e do Autopilot com o escalonamento automático vertical de pods ativado. Acelerar a inicialização vinculada à CPU para ambientes de execução como Java, Python ou Node.js.

Escolher uma estratégia por etapa de inicialização de pods

As seções a seguir descrevem as opções disponíveis para cada etapa do ciclo de vida de inicialização de pods.

Acelerar o provisionamento de nós e a programação de pods

Quando os pods pendentes não cabem nos nós atuais, esperar que um novo nó seja inicializado geralmente é o maior contribuinte para a latência de escalonamento. É possível reduzir ou eliminar esse atraso usando as seguintes estratégias:

  • Use buffers de capacidade para reservar declarativamente a capacidade extra de nós:
    • Configure um buffer ativo (estratégia buffer.x-k8s.io/active-capacity) para manter os nós pré-provisionados em execução e prontos para programar pods imediatamente. Os buffers ativos oferecem suporte a cargas de trabalho de CPU, GPU e TPU.
    • Configure um buffer de espera (estratégia buffer.gke.io/standby-capacity) para manter os nós de CPU pré-provisionados em um estado suspenso. Quando as cargas de trabalho escalonar verticalmente, o GKE retoma os nós de espera em aproximadamente 30 a 35 segundos, evitando o custo total de computação de VMs ociosas.
  • Confie em nós de inicialização rápida para pré-inicialização automática de hardware da melhor maneira possível em cargas de trabalho qualificadas do Autopilot e séries de máquinas de GPU. Quando o GKE provisiona novos nós para uma carga de trabalho qualificada, ele usa automaticamente nós de inicialização rápida. Isso inclui nós criados para reabastecer um buffer de capacidade em uma ComputeClass personalizada do Autopilot compatível.
  • Implante pods de marcador de posição de baixa prioridade com PriorityClasses do Kubernetes se as cargas de trabalho usarem o modelo de faturamento baseado em pods do Autopilot ou forem executadas em versões do GKE anteriores à 1.35. Para clusters que usam o faturamento baseado em nós em versões compatíveis do GKE, prefira buffers de capacidade declarativos, porque eles não exigem o gerenciamento de implantações de marcador de posição ou loops de remoção de pods.

Acelerar extrações de imagens de contêiner

Depois que o programador coloca um pod em um nó, o nó precisa extrair a imagem do contêiner antes de iniciar o contêiner. É possível reduzir a latência de extração de imagens usando as seguintes estratégias:

  • Ative o streaming de imagens para permitir que os contêineres sejam iniciados assim que os arquivos necessários forem transmitidos pela rede, enquanto o restante da imagem é baixado em segundo plano. Os clusters do Autopilot ativam o streaming de imagens por padrão para imagens qualificadas no Artifact Registry.
  • Configure discos de inicialização secundários para pré-carregar grandes camadas de base de contêiner ou conjuntos de dados estáticos em uma imagem de disco personalizada. Quando o GKE cria um nó, ele anexa um Persistent Disk instanciado da imagem do disco em paralelo com o provisionamento de nós.
  • Execute um DaemonSet para pré-carregar imagens de contêiner em buffers de espera durante a janela de inicialização do nó (buffer.gke.io/standby-capacity-init-time anotação). Antes que o GKE suspenda um nó de espera, o DaemonSet extrai as imagens da carga de trabalho para o disco de inicialização do nó para que as imagens já estejam armazenadas em cache quando o nó for retomado.

Acelerar a inicialização do aplicativo

Mesmo depois que um nó está em execução e a imagem do contêiner está presente, os aplicativos podem levar um tempo significativo para carregar frameworks, compilar código just-in-time (JIT) ou carregar pesos de modelo na memória. É possível reduzir o tempo de inicialização usando as seguintes estratégias:

  • Configure snapshots de pods para capturar um checkpoint da memória de um pod em execução e do estado do sistema de arquivos no GKE Sandbox. Quando a carga de trabalho é escalonada horizontalmente, o GKE restaura novas réplicas do snapshot no Cloud Storage para que o pod retome a execução do ponto em que o snapshot foi feito, em vez de inicializar de um estado novo.
  • Configure otimização de inicialização da CPU em um VerticalPodAutoscaler para alocar CPU extra a um pod durante a admissão e a inicialização. Depois que o pod atinge o status Ready e a duração da otimização configurada termina, o GKE reduz a solicitação de CPU do pod de volta ao nível de referência no local sem reiniciar o contêiner.

Combinar estratégias para otimização de ponta a ponta

Como essas estratégias operam em diferentes etapas do ciclo de vida de inicialização de pods, é possível combiná-las para otimizar o tempo de escalonamento de ponta a ponta:

  • Combine um buffer de capacidade ativa pequeno com um buffer de capacidade de espera maior. Durante um pico de tráfego repentino, o buffer ativo absorve o burst inicial de pods imediatamente. Enquanto isso, o GKE retoma os nós do buffer de espera em aproximadamente 30 a 35 segundos para reabastecer o buffer ativo e lidar com o crescimento sustentado. Em segundo plano, o escalonador automático de clusters provisiona e suspende novos nós para reabastecer o buffer de espera.
  • Para buffers de capacidade de espera, ative o streaming de imagens ou pré-carregue imagens do contêiner usando um DaemonSet antes que o nó seja suspenso para que ele não gaste tempo fazendo o download de imagens do contêiner grandes quando for retomado.
  • Combine a otimização de inicialização da CPU ou snapshots de pods em buffers de capacidade ou nós de inicialização rápida para que, depois que o GKE programar um pod em um nó pré-provisionado ou pré-inicializado, o pod evite a limitação da CPU durante a inicialização ou restaure diretamente de um snapshot salvo.

Para medir o efeito de qualquer estratégia única ou combinada nas cargas de trabalho, consulte os gráficos Distribuição de latência de inicialização de pods e Latência do primeiro pod pronto no Cloud Monitoring e inspecione os registros de latência de programação no Cloud Logging. Para instruções, consulte Monitorar métricas de latência de inicialização.

A seguir