Sobre buffers de capacidade

Os buffers de capacidade ajudam a reduzir a latência de inicialização do pod para suas cargas de trabalho do Google Kubernetes Engine (GKE), permitindo que você declare proativamente níveis de buffers de capacidade ativos ou em espera no cluster. Ao declarar capacidade extra com antecedência, você consegue inicializações mais rápidas de cargas de trabalho de maneira econômica.

Este documento explica como os buffers de capacidade funcionam. Para saber como ativar e usar buffers de capacidade, consulte Configurar buffers de capacidade.

Quando usar buffers de capacidade

Use buffers de capacidade para aplicativos sensíveis à latência de inicialização e que precisam ser escalonados rapidamente. Quando você tem aumentos repentinos no tráfego, um buffer ativo oferece capacidade pré-provisionada projetada para escalonamento de baixa latência. Quando você tem um aumento constante no tráfego, um buffer de espera fornece o agendamento de pods a um custo mais acessível do que o pré-provisionamento.

Os buffers de capacidade oferecem os seguintes benefícios:

  • Minimizar a latência de escalonamento: os buffers ativos fornecem nós em execução, o que ajuda a minimizar a latência. Os buffers em espera são retomados rapidamente, oferecendo disponibilidade de capacidade mais rápida do que nós novos a um custo menor em comparação com os buffers ativos.
  • Provisionamento excessivo econômico: os buffers de capacidade ajudam a manter uma rede de segurança. Para cargas de trabalho em grande escala, essa abordagem costuma ser mais econômica do que outros métodos de provisionamento excessivo, como reduzir as metas de utilização do escalonador automático de pod horizontal (HPA), que podem aumentar a capacidade ociosa linearmente à medida que o cluster cresce.
  • Atenda aos requisitos de carga de trabalho:você tem controle total sobre a configuração do buffer de capacidade. Suas opções incluem incorporar daemonsets personalizados para pré-carregar imagens, ajustar o tempo de inicialização e controlar os tamanhos de buffer para atender às suas necessidades.

Recomendamos buffers de capacidade para cargas de trabalho sensíveis à latência que exigem escalonamento rápido, como agentes de IA, inferência de IA, aplicativos de varejo durante eventos de vendas ou servidores de jogos durante o pico de atividade dos jogadores.

Como funcionam os buffers de capacidade

Implemente um buffer de capacidade usando um recurso personalizado CapacityBuffer do Kubernetes para definir um buffer de capacidade disponível. O escalonador automático de cluster do GKE monitora recursos CapacityBuffer e os trata como demanda pendente para garantir que a capacidade extra esteja disponível. Se o cluster não tiver capacidade suficiente para atender às solicitações de recursos definidas no buffer, o escalonador automático de cluster vai provisionar nós extras.

Quando uma carga de trabalho de alta prioridade é escalonada, o GKE a programa na capacidade disponível no buffer imediatamente. Esse agendamento imediato se aplica ao número de réplicas ou à quantidade de recursos reservada no buffer, evitando o atraso típico associado ao provisionamento de nós. Quando uma carga de trabalho usa uma unidade de buffer, o escalonador automático de cluster provisiona um novo nó para preencher o buffer.

Estratégias de buffer de capacidade

É possível configurar buffers de capacidade usando diferentes estratégias de provisionamento com base nos requisitos de latência e custo.

Buffer ativo

Um buffer ativo fornece nós em execução para escalonamento de baixa latência de cargas de trabalho que se encaixam na capacidade reservada. Como os nós já estão em execução, eles oferecem latência mínima para reivindicar pods durante um evento de escalonamento vertical.

Buffer de espera

Um buffer de espera fornece nós suspensos. A estratégia de espera é mais econômica do que a ativa, mas introduz um pequeno atraso para retomar o nó antes que ele aceite cargas de trabalho.

Custo e preços

O faturamento dos buffers de capacidade varia de acordo com o tipo de buffer:

  • Buffers ativos: você recebe cobranças de taxas de computação do GKE padrão pelas VMs em execução que o GKE mantém para servir como capacidade de buffer ativo. No Autopilot, as taxas padrão de faturamento baseadas em pods se aplicam aos pods em execução.
  • Buffers de espera: enquanto as instâncias de VM estão suspensas, você não paga custos de computação (CPU ou memória). Você incorre em pequenas taxas de armazenamento (por exemplo, discos de inicialização de VM) e custos de recursos associados, como endereços IP externo estáticos. Quando o GKE retoma as VMs em espera para hospedar cargas de trabalho, as taxas de faturamento padrão de computação ou com base em pods são aplicadas.

CRD CapacityBuffer

Para configurar um buffer de capacidade, crie uma CustomResourceDefinition (CRD) do CapacityBuffer. É possível configurar o buffer de capacidade para atender a diferentes critérios:

  • Réplicas fixas: especifique um número fixo de pods de buffer a serem criados com base nas solicitações de recursos de um modelo de pod referenciado. Essa configuração é a maneira mais simples de criar um buffer de tamanho conhecido.
  • Limites de recursos: especifique a quantidade total de CPU e memória que o buffer deve reservar. O controlador calcula quantos pods de buffer criar com base nas solicitações de recursos de um modelo de pod referenciado.
  • Baseado em porcentagem: defina o tamanho do buffer como uma porcentagem de um objeto escalonável que define um sub-recurso de escalonamento (como um Deployment, StatefulSet, ReplicaSet ou Job). O tamanho do buffer é ajustado dinamicamente à medida que a carga de trabalho de referência é escalonada. Buffers de capacidade baseados em porcentagem só são compatíveis com objetos que implementam o subrecurso de escalonamento do Kubernetes.

Para mais informações, consulte a documentação de referência do CRD CapacityBuffer.

Práticas recomendadas

Para otimizar a eficiência de custos e a capacidade de resposta ao configurar buffers de capacidade, use as seguintes recomendações:

  • Use uma estratégia de custo ideal e de espera em primeiro lugar: priorize buffers de espera se as cargas de trabalho puderem tolerar um breve atraso de escalonamento vertical de aproximadamente 30 segundos. Essa estratégia evita inicializações de nós frios de VMs novas sem ter que incorrer no custo total das VMs ativas.
  • Usar buffers ativos para cargas de trabalho sensíveis à latência: use buffers ativos para cargas de trabalho que não podem tolerar tempos de retomada de nós quando o tempo de programação de pods precisa ser o menor possível.
  • Use uma estratégia híbrida para equilibrar performance e custo: combine um pequeno buffer ativo com um buffer de espera maior para uma configuração econômica. O GKE prioriza o reabastecimento do buffer ativo retomando os nós do buffer de espera (levando cerca de 30 segundos), enquanto novos nós são provisionados em segundo plano para preencher o buffer de espera. Essa configuração absorve picos iniciais com capacidade ativa e acomoda o crescimento sustentado usando a capacidade de espera de menor custo.
  • Dimensionar buffers ativos para picos iniciais: defina o tamanho do buffer ativo para cobrir os picos iniciais e repentinos de réplicas que você espera encontrar antes que os nós de buffer em espera possam ser retomados.
  • Dimensionar buffers de espera para carga sustentada: defina buffers de espera suficientes para cobrir a carga estendida que você espera encontrar. Assim, os buffers podem ser preenchidos em segundo plano a partir de uma inicialização a frio. Um buffer de espera de tamanho suficiente pode reduzir a latência máxima de programação de pods para o tempo necessário para retomar um nó, que é de aproximadamente 30 segundos. Quando o buffer de capacidade começa a ser usado e é reabastecido, novos nós de buffer fazem a transição para um estado ativo antes da suspensão. Essa estratégia ajuda a aumentar a capacidade ativa durante uma carga prolongada.
  • Use o simulador de buffer: teste diferentes tamanhos de buffer ativo e em espera para ter o melhor resultado para sua carga de trabalho específica. Execute simulações do comportamento de escalonamento de carga de trabalho usando o simulador de buffers do GKE de código aberto em https://github.com/gke-labs/buffers-simulator para ajustar as regras de dimensionamento de buffer e alcançar as metas de desempenho.
  • Reduza a latência de inicialização a frio ao escalonar cargas de trabalho de zero: pareie cargas de trabalho que escalonam para e de zero usando HPA (minReplicas: 0) com buffers de capacidade. Quando a demanda aumenta e a carga de trabalho é escalonada de zero, o GKE programa imediatamente os pods em nós de buffer pré-aquecidos em vez de esperar que novos nós de computação sejam provisionados.

Requisitos e limitações

Os buffers de capacidade têm os seguintes requisitos e limitações:

  • Os buffers de capacidade estão disponíveis para clusters do GKE que executam a versão 1.35.2-gke.1842000 ou mais recente para buffers ativos e a versão 1.36.0-gke.2253000 para buffers em espera.
  • Os buffers de capacidade só são compatíveis com cargas de trabalho que usam um modelo de faturamento baseado em nós para pools de nós padrão e pools de nós do Autopilot que selecionam hardware específico. Os buffers de capacidade não são compatíveis com cargas de trabalho que usam o modelo de faturamento baseado em pods.
  • Em clusters padrão, recomendamos que você ative o provisionamento automático de nós. O provisionamento automático de nós permite que o escalonador automático de cluster crie novos pools de nós com base nas solicitações de recursos no CapacityBuffer. Se você não ativar o provisionamento automático de nós, o escalonador automático de cluster vai aumentar apenas os pools de nós atuais.
  • Os buffers de capacidade ativa e em espera contam para as cotas do Compute Engine.
  • Se a dependência de configuração do CapacityBuffer (por exemplo, um PodTemplate) selecionar uma ComputeClass personalizada, a dependência precisará definir todas as tolerâncias, seletores de nós ou classes de tempo de execução necessárias para o agendamento nos nós provisionados (por exemplo, requisitos para GKE Sandbox). Para instruções, consulte a documentação da ComputeClass personalizada.

Os buffers de espera têm as seguintes limitações adicionais:

  • Eles são compatíveis com clusters padrão com o provisionamento automático de nós ativado.
  • Eles são compatíveis com clusters do Autopilot que executam a versão 1.36.0-gke.2853000 ou mais recente.
  • Não há suporte para nós com GPUs ou TPUs anexadas.
  • Os SSDs locais não são compatíveis.
  • Os Nós confidenciais do Google Kubernetes Engine estão indisponíveis.
  • Você precisa conhecer as limitações relacionadas às operações de suspensão e retomada do Compute Engine. Algumas limitações importantes incluem:
    • Nós com discos protegidos por chaves de criptografia fornecidas pelo cliente (CSEK) são indisponíveis.
    • Não é possível usar nós com mais de 208 GB de memória.
    • As instâncias bare metal não são compatíveis.
    • O SO do nó precisa ser compatível com sinais de suspensão ACPI S3.
    • A duração do processo de suspensão é proporcional ao tamanho da memória.
    • A retomada depende da disponibilidade dos recursos necessários.

A seguir