Sobre buffers de capacidade

Standard Autopilot

Visualizar

Este produto está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os produtos pré-GA estão disponíveis no estado em que se encontram e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Os buffers de capacidade ajudam a reduzir a latência de inicialização de pods 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 a capacidade extra com antecedência, é possível acelerar as inicializações de cargas de trabalho de maneira econômica.

Neste documento, explicamos como funcionam os buffers de capacidade. 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 que são sensíveis à latência de inicialização e precisam ser escalonados rapidamente. Quando você tem aumentos repentinos no tráfego, um buffer ativo fornece capacidade pré-provisionada projetada para escalonamento de baixa latência. Quando você tem um aumento sustentado no tráfego, um buffer de espera fornece programação 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 de espera são retomados rapidamente, oferecendo disponibilidade de capacidade mais rápida do que os nós novos a um custo menor em comparação com os buffers ativos.
• Superprovisionamento 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 superprovisionamento, como reduzir as metas de utilização do escalonador automático horizontal de pods (HPA, na sigla em inglês), o que pode aumentar a capacidade ociosa de forma linear à medida que o cluster cresce.
• Atender aos requisitos de carga de trabalho:você tem controle total sobre a configuração do buffer de capacidade. As 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 vertical 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 os 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 clusters provisionará nós adicionais.

Quando uma carga de trabalho é escalonada verticalmente, o GKE programa os pods pendentes na capacidade disponível na seguinte ordem de prioridade:

1. Nós em execução em um buffer ativo
2. Nós em execução em um buffer de espera que ainda não foram suspensos
3. Nós suspensos em um buffer de espera
4. Nós recém-provisionados

Para programar pods pendentes o mais rápido possível, o GKE usa a capacidade de buffer disponível antes de provisionar novos nós. Essa prioridade se aplica mesmo que uma regra de prioridade mais alta em uma ComputeClass personalizada provisione um novo nó.

A capacidade do buffer não é restrita à carga de trabalho referenciada no campo scalableRef. Qualquer pod pendente com restrições de programação, como seletores de nós, tolerâncias e solicitações de recursos, que correspondam à configuração do nó de buffer pode reivindicar essa capacidade. Para reservar um buffer de capacidade para uma carga de trabalho específica, configure a separação de cargas de trabalho adicionando tolerâncias e seletores de nós (ou afinidades de nós) correspondentes à carga de trabalho e ao buffer de capacidade.

Quando uma carga de trabalho consome capacidade de um buffer ativo, o escalonador automático de cluster reabastece o buffer ativo retomando um nó de um buffer de espera compatível, se houver, ou provisionando um novo nó. Quando uma carga de trabalho ou um buffer ativo consome um nó de um buffer de espera, o escalonador automático de cluster reabastece o buffer de espera provisionando e suspendendo um novo nó. Quando a carga de trabalho é reduzida e os nós ficam subutilizados, o escalonador automático de cluster exclui os nós em excesso após a janela de estabilização de redução, em vez de suspendê-los novamente no buffer de espera. Para reabastecer o buffer de espera, o GKE provisiona e suspende novos nós separadamente.

Estratégias de buffer de capacidade

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

Buffer ativo

Um buffer ativo fornece nós em execução para o 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 de aceitar cargas de trabalho.

Custo e preços

Os buffers de capacidade são fornecidos sem custo financeiro adicional, além dos custos de computação padrão baseados em nós, que se aplicam a pools de nós padrão e cargas de trabalho do Autopilot que selecionam hardware específico. Os buffers de capacidade não são compatíveis com o modelo de faturamento baseado em pods.

O faturamento dos nós subjacentes varia de acordo com o tipo de buffer:

• Buffers ativos: você recebe cobranças de taxas de computação padrão baseadas em nós pelas VMs em execução que o GKE mantém para servir como capacidade de buffer ativo.
• 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ê vai receber pequenas cobranças de armazenamento (por exemplo, discos de inicialização de VM e estado de memória armazenado) 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 computação padrão baseadas em nós são aplicadas. Para mais informações, consulte Preços de instâncias suspensas.

CRD CapacityBuffer

Para configurar um buffer de capacidade, crie um CustomResourceDefinition (CRD) 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 precisa reservar. O controlador calcula quantos pods de buffer devem ser criados 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 existente que define um sub-recurso de escalonamento (como uma implantação, StatefulSet, ReplicaSet ou job). O tamanho do buffer se ajusta dinamicamente conforme a carga de trabalho de referência é escalonada. Os buffers de capacidade baseados em porcentagem só são compatíveis com objetos que implementam o subrecurso de escalonamento do Kubernetes.

É possível combinar essas opções, por exemplo, definindo replicas e percentage para que o GKE use o valor maior como um limite mínimo e definindo limits como um limite superior.

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 otimizado e prioridade de espera: priorize os 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 precisar incorrer no custo total de VMs ativas.
• Use buffers ativos para cargas de trabalho sensíveis à latência: use buffers ativos para cargas de trabalho que não toleram 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 desempenho e custo: combine um pequeno buffer ativo com um buffer de espera maior para uma configuração econômica. O GKE prioriza o preenchimento 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.
• Defina o tamanho dos buffers ativos para picos iniciais: defina o tamanho do buffer ativo para cobrir os picos repentinos iniciais 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, para que eles possam 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 é preenchido, novos nós de buffer passam para um estado ativo antes de serem suspensos. 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 conseguir o melhor resultado para sua carga de trabalho específica. Execute simulações do comportamento de escalonamento de cargas 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 buffers e atingir as metas de desempenho.
• Reduzir a latência de inicialização a frio ao escalonar cargas de trabalho do zero: combine cargas de trabalho que escalonam de e para zero usando o HPA (minReplicas: 0) com buffers de capacidade. Quando a demanda aumenta e a carga de trabalho é escalonada verticalmente a partir 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.
• Considere o perfil de escalonamento automático optimize-utilization em clusters padrão: como os buffers de capacidade já mantêm espaço livre, é possível configurar o perfil de escalonamento automático optimize-utilization (--autoscaling-profile=optimize-utilization) para que o escalonador automático de cluster reduza a escala vertical de nós subutilizados mais rapidamente após a queda da demanda. Esse perfil também empacota os pods de maneira mais compacta nos nós. Portanto, avalie se o empacotamento mais compacto se ajusta aos requisitos de disponibilidade da carga de trabalho antes de ativá-lo.

Calcular o tamanho do buffer

Ao combinar um buffer ativo com um buffer de espera, é possível estimar o número de réplicas de buffer ou pods de buffer simulados necessários para absorver um pico de tráfego. Calcule essa estimativa usando a taxa de escalonamento vertical esperada em pods por segundo, a latência de retomada do nó em espera e a latência de criação do nó frio. Essas latências variam de acordo com a série de máquinas da VM e a configuração do nó. Por exemplo, a latência de retomada do nó em espera normalmente é de 30 a 35 segundos, e a latência de criação de um novo nó normalmente é de 60 a 120 segundos, dependendo da série de máquinas. Para medir as latências reais do cluster, consulte Monitorar métricas de latência de inicialização.

1. Calcule o tamanho do buffer ativo para cobrir os pods criados enquanto os nós em espera são retomados:

   \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

2. Calcule o tamanho do buffer de espera para cobrir os pods restantes criados enquanto os novos nós frios terminam o provisionamento:

   \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

Por exemplo, se a carga de trabalho for escalonada verticalmente em dois pods por segundo, os nós em espera vão levar 30 segundos para serem retomados, e os novos nós frios vão levar 90 segundos para serem provisionados:

• O buffer ativo precisa de \( 2 \times 30 = 60 \) réplicas para absorver os primeiros 30 segundos do pico.
• Seu buffer de espera precisa de réplicas \( (2 \times 90) - 60 = 120 \) para cobrir os 60 segundos restantes enquanto o escalonador automático de clusters provisiona novos nós frios em segundo plano para reabastecer os buffers. Se o pico continuar por mais de 90 segundos na mesma taxa, esses nós reabastecidos estarão prontos para atender aos pods recebidos sem tempo de espera.

Para testar essas estimativas em relação aos padrões de escalonamento de carga de trabalho, execute simulações com o simulador de buffers do GKE.

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 de espera.
• Os buffers de capacidade são compatíveis apenas 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 ativar a criação automática de pools de nós. A criação automática de pools 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 a criação automática de pool de nós, o escalonador automático de clusters só vai escalonar verticalmente os pools de nós atuais.
• Os buffers de capacidade ativa e em espera consomem cotas de maneira diferente:
  • Os nós em execução em um buffer ativo são contabilizados nas cotas do Compute Engine de vCPU, memória, disco e endereço IP.
  • Os nós suspensos em um buffer de espera não são contabilizados nas cotas de vCPU ou memória do Compute Engine enquanto estão suspensos. No entanto, elas continuam consumindo cotas de endereço IP e cotas de disco, incluindo a cota de Persistent disk standard (GB) usada para armazenar a memória da VM suspensa.
  • No Kubernetes, as unidades de buffer de espera ativas e suspensas contam para as cotas de recursos do Kubernetes no namespace como se os pods de buffer estivessem em execução.
• Se a dependência de configuração do CapacityBuffer (por exemplo, um PodTemplate) selecionar uma ComputeClass personalizada, ela precisará definir as tolerâncias, os seletores de nós ou as classes de ambiente de execução necessárias para programar nos nós provisionados (por exemplo, requisitos para o 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 Standard que têm a criação automática de pools de nós ativada.
• Eles são compatíveis com clusters do Autopilot que executam a versão 1.36.0-gke.2853000 ou mais recente.
• Nós com GPUs ou TPUs anexadas não são compatíveis.
• Os SSDs locais não são compatíveis.
• Embora os buffers de espera sejam compatíveis com chaves de criptografia gerenciadas pelo cliente (CMEK) para o armazenamento do nó, a memória do nó é criptografada usando Google-owned and Google-managed encryption keys durante a suspensão.
• Os nós confidenciais do Google Kubernetes Engine não são compatíveis.
• Os buffers de espera são compatíveis apenas com o GKE Imagens de nó do Container-Optimized OS e do Ubuntu. Os nós do Windows Server não são compatíveis. Se você usar um sistema operacional de nó personalizado, verifique se ele é compatível com as operações de suspensão e retomada do Compute Engine.
• Conheça as limitações relacionadas às operações de suspensão e retomada do Compute Engine. Algumas limitações importantes incluem:
  • Não há suporte para nós com discos protegidos por chaves de criptografia fornecidas pelo cliente (CSEK).
  • Nós com mais de 208 GB de memória não são compatíveis.
  • Não há suporte para instâncias bare metal.
  • O SO do nó precisa ser compatível com os sinais de suspensão ACPI S3.
  • A duração do processo de suspensão é proporcional ao tamanho da memória.

Importante: para retomar um nó em espera, é necessário ter capacidade zonal do Compute Engine disponível para o tipo de máquina do nó e a geração específica da plataforma de CPU (como na série de máquinas E2 ou N2). Além disso, as VMs spot suspensas não podem ser convertidas em VMs sob demanda ao serem retomadas.

A seguir

• Para saber como implementar um buffer de capacidade, consulte Configurar buffers de capacidade.