Os buffers de capacidade ajudam a reduzir a latência de inicialização de pods para cargas de trabalho do Google Kubernetes Engine (GKE), permitindo que você declare proativamente níveis de buffers de capacidade ativos ou de espera no cluster. Ao declarar capacidade extra com antecedência, você pode conseguir inicializações de carga de trabalho mais rápidas 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 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 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 de 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 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 geralmente é mais econômica do que outros métodos de provisionamento excessivo (por exemplo, reduzir as metas de utilização do HorizontalPodAutoscaler (HPA)), que podem aumentar a capacidade ociosa linearmente à medida que o cluster cresce.
- Atender aos requisitos da carga de trabalho:você tem controle total sobre a configuração do buffer de capacidade. As opções incluem a incorporação de daemonsets personalizados para pré-carregar imagens, ajustar o tempo de inicialização e controlar os tamanhos do 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 a atividade máxima do jogador.
Como os buffers de capacidade funcionam
Implemente um buffer de capacidade usando um recurso personalizado do Kubernetes CapacityBuffer para definir um buffer de capacidade extra. O escalonador automático de cluster do GKE monitora os recursos do CapacityBuffer e os trata como demanda pendente para ajudar a 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 extras.
Quando uma carga de trabalho de alta prioridade é escalonada verticalmente, o GKE agenda a carga de trabalho 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 clusters 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 de buffers de capacidade varia dependendo do tipo de buffer:
- Buffers ativos: você recebe cobranças de taxas de computação padrão do GKE pelas VMs em execução que o GKE mantém para servir como capacidade de buffer ativa. No Autopilot, as taxas de faturamento padrão baseadas em pods são aplicadas 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 cobranças 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 de espera para hospedar cargas de trabalho, as taxas de faturamento padrão de computação ou baseadas em pods são aplicadas.
CRD CapacityBuffer
Para configurar um buffer de capacidade, crie uma CapacityBuffer CustomResourceDefinition (CRD). É 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 em solicitações de recursos de um modelo de pod referenciado. Essa configuração é a maneira mais simples de criar um buffer de um 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 criar com base nas solicitações de recursos de um modelo de pod referenciado.
- Com base em porcentagem: defina o tamanho do buffer como uma porcentagem de um objeto escalonável atual que define um sub-recurso de escalonamento (como uma implantação, um StatefulSet, um ReplicaSet ou um job). O tamanho do buffer é ajustado dinamicamente à medida que a carga de trabalho de referência é escalonada. Os buffers de capacidade baseados em porcentagem são compatíveis apenas com objetos que implementam o sub-recurso de escalonamento do Kubernetes.
Para mais informações, consulte a documentação de referência do CRD CapacityBuffer.
Práticas recomendadas
Para otimizar a relação custo-benefício e a capacidade de resposta ao configurar buffers de capacidade, use as seguintes recomendações:
- Use uma estratégia econômica e de espera primeiro: 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 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 podem tolerar tempos de retomada de nós quando o tempo de agendamento 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 preenchimento do buffer ativo retomando 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.
- Tamanho dos buffers ativos para bursts iniciais: defina o tamanho do buffer ativo para cobrir os picos de réplica repentinos iniciais que você espera encontrar, antes que os nós do buffer de espera possam ser retomados.
- Tamanho dos buffers de espera para carga sustentada: defina buffers de espera que sejam suficientes para cobrir a carga estendida que você espera encontrar, para que os buffers possam ser preenchidos em segundo plano a partir de uma inicialização a frio. Um buffer de espera com tamanho suficiente pode reduzir a latência máxima de agendamento 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 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 ativos e de espera para conseguir 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 performance.
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 oferecem suporte apenas a 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 oferecem suporte a cargas de trabalho que usam o modelo de faturamento baseado em pods.
- Em clusters padrão, recomendamos ativar o provisionamento automático de nós. O provisionamento automático de nós permite que o escalonador automático de clusters 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 clusters só vai escalonar os pools de nós atuais.
- Os buffers de capacidade ativos e de espera são contabilizados nas cotas do Compute Engine.
Os buffers de espera têm as seguintes limitações adicionais:
- Eles são compatíveis apenas com clusters padrão com o provisionamento automático de nós ativado.
- Não há suporte para nós com GPUs ou TPUs anexadas.
- Não há suporte para SSDs locais.
- As chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) não são compatíveis.
- Não há suporte para nós confidenciais do Google Kubernetes Engine.
- Você precisa estar familiarizado com as limitações relacionadas às operações de suspensão e retomada do Compute Engine.
Algumas limitações importantes incluem o seguinte:
- Nós com discos protegidos por chaves de criptografia fornecidas pelo cliente (CSEK) são indisponíveis.
- Não há suporte para nós com mais de 208 GB de memória.
- Não há suporte para instâncias bare metal.
- O SO do nó precisa oferecer suporte a sinais de suspensão ACPI S3.
- O comprimento do processo de suspensão é proporcional ao tamanho da memória.
- A retomada depende da capacidade de obtenção dos recursos subjacentes necessários para retomar.
A seguir
- Para saber como implementar um buffer de capacidade, consulte Configurar buffers de capacidade.