Este documento apresenta uma visão geral dos conceitos de escalonamento automático para cargas de trabalho de IA/ML no Google Kubernetes Engine (GKE).
Este documento é destinado a engenheiros de machine learning (ML) que não conhecem o GKE. Recomendamos que você leia os seguintes documentos da série para facilitar o uso do GKE em cargas de trabalho de IA/ML:
- Por que usar o GKE para inferência de IA/ML?
- Sobre a inferência de modelos de IA/ML no GKE
- Conceitos simplificados de escalonamento automático para cargas de trabalho de IA/ML no GKE (este documento)
Antes de começar
Você precisa ter familiaridade básica com os seguintes conceitos:
- Objetos fundamentais do Kubernetes: entenda o que são contêineres, pods e nós e como eles se relacionam.
- Arquitetura básica do cluster do GKE: entenda como os vários componentes do cluster do GKE interagem entre si.
O desafio: atender à demanda máxima
A Cymbal Shops, uma loja on-line fictícia, está se preparando para o evento anual de vendas. O mecanismo de recomendação com tecnologia de IA da loja precisa fornecer sugestões personalizadas em tempo real para um grande fluxo de compradores on-line.
Se o mecanismo de recomendação ficar mais lento, a experiência do usuário será prejudicada e as vendas serão perdidas. No entanto, provisionar capacidade excessiva do servidor não é econômico durante períodos de tráfego normal. O objetivo é que os recursos sejam escalonados automaticamente em resposta à demanda, garantindo uma boa experiência do usuário e mantendo os custos sob controle.
A solução: escalonamento automático sob demanda
O escalonamento automático do GKE funciona como um gerente de loja se preparando para um período de vendas intenso. Em vez de manter um prédio enorme com equipe completa e energia o tempo todo, o gerente ajusta dinamicamente toda a capacidade da loja (funcionários, espaço físico e equipamentos) para atender às necessidades dos compradores a qualquer momento.
O GKE aplica o mesmo princípio: ele escalona automaticamente os recursos alocados ao aplicativo (carga de trabalho e infraestrutura) com base na demanda em tempo real.
Benefícios comerciais do escalonamento automático do GKE
Ao combinar estratégias de escalonamento horizontal e vertical, o GKE oferece uma abordagem robusta com três benefícios principais:
- Otimização de custos: você paga apenas pelos recursos de computação que usa e evita o gasto de provisionamento excessivo. O escalonamento automático do GKE evita o desperdício ao dimensionar automaticamente seus aplicativos de acordo com os requisitos reais de CPU e memória. Ele também pode provisionar hardware caro e especializado (como GPUs) apenas quando necessário e removê-los quando o job for concluído.
- Confiabilidade e desempenho aprimorados: seu aplicativo pode ser escalonar horizontalmente horizontalmente (adicionar mais cópias) de forma automática para lidar com picos repentinos de tráfego, garantindo a estabilidade para os usuários. Ao mesmo tempo, o escalonamento automático do GKE ajuda a evitar erros comuns de "falta de memória" (OOM, na sigla em inglês) que podem causar falhas nos aplicativos. Para os trabalhos exigentes de IA/ML, ele ajuda a garantir que o hardware de alto desempenho necessário esteja disponível para executar e concluir os trabalhos a tempo.
- Redução da sobrecarga operacional: a estratégia de escalonamento automático multidimensional do GKE simplifica significativamente o gerenciamento de recursos. O GKE automatiza as tarefas complexas de ajuste de solicitações de recursos e gerenciamento de pools de nós especializados para diferentes hardwares. Essa automação libera as equipes de engenharia para se concentrarem no desenvolvimento de aplicativos em vez de ajustar a infraestrutura.
Escalonamento automático de carga de trabalho
O escalonamento automático de carga de trabalho ajusta automaticamente a capacidade do aplicativo para atender à demanda. O GKE usa um sistema de escalonamento automático de dois níveis para gerenciar os recursos do aplicativo de maneira eficiente.
Escalonador automático horizontal de pods (HPA): adição de mais recursos
O escalonador automático horizontal de pods (HPA) monitora a utilização de recursos dos pods do seu aplicativo. Na nossa analogia, os pods são os "associados de vendas", e o HPA é o "gerente de equipe" que observa o movimento dos associados de vendas.
Quando a demanda nos pods aumenta, o HPA provisiona automaticamente mais pods para distribuir a carga. Quando a demanda diminui, o HPA encerra os pods inativos para economizar recursos.
Para mais informações, consulte Escalonamento automático horizontal de pods.
Escalonador automático vertical de pods (VPA): tornando os recursos mais eficientes
Enquanto o escalonamento horizontal se concentra em aumentar a quantidade de recursos, o escalonamento vertical é uma estratégia complementar que se concentra em aumentar a capacidade dos recursos atuais. No contexto da nossa analogia de loja física, não se trata de contratar mais funcionários, mas de aumentar as capacidades da equipe atual para melhorar a eficiência individual.
Essa abordagem de escalonamento vertical no nível do pod é gerenciada pelo escalonador automático vertical de pods (VPA, na sigla em inglês). O VPA analisa o consumo de recursos do aplicativo e ajusta as solicitações de CPU e memória do pod para cima ou para baixo, de acordo com o uso real.
O VPA pode ajustar as solicitações e os limites de recursos de um pod, por exemplo, ao reaprovisionar o pod para escalonar de 1 CPU e 16 GB para 4 CPUs e 64 GB. Esse processo envolve reiniciar o pod com a nova configuração, mais eficiente, para lidar melhor com a carga de trabalho.
Para saber mais, acesse os recursos a seguir:
HPA e VPA são complementares. O HPA ajusta o número de pods em resposta a mudanças no tráfego, e o VPA ajuda a garantir que cada um desses pods tenha o tamanho correto para a tarefa. Essas estratégias evitam o desperdício de recursos e custos desnecessários, além de ajudar a garantir que seu app permaneça responsivo e disponível durante as variações de tráfego. No entanto, não recomendamos usar HPA e VPA nas mesmas métricas (CPU e memória) porque elas podem entrar em conflito. Para mais informações, consulte Limitações do escalonamento automático horizontal de pods.
Escalonamento automático de infraestrutura
O escalonamento automático de infraestrutura adiciona ou remove hardware automaticamente para atender às demandas das suas cargas de trabalho.
Escalonador automático de cluster: o gerente do prédio
O escalonador automático de cluster ajuda a garantir que haja infraestrutura subjacente suficiente (VMs ou nós no contexto do GKE) para acomodar os pods. Os nós podem ser comparados aos "andares" de uma loja, em que o escalonador automático de cluster é o "administrador do prédio".
Se o HPA precisar adicionar mais pods, mas os nós atuais não tiverem capacidade disponível, o escalonador automático de cluster vai provisionar um novo nó. Por outro lado, se um nó ficar subutilizado, o autoescalador de cluster moverá os pods desse nó para outros nós e encerrará o nó agora vazio.
Para mais informações, consulte Escalonador automático de cluster.
Criação automática de pool de nós: o especialista em automação
Enquanto o escalonador automático de cluster adiciona nós aos pools de nós atuais, a criação automática de pool de nós estende a capacidade do escalonador automático de cluster, permitindo que ele crie automaticamente novos pools de nós que atendam às necessidades específicas dos seus pods.
Algumas cargas de trabalho de IA/ML exigem hardware especializado de alta performance, como GPUs ou TPUs, que não estão disponíveis em pools de nós de uso geral. A criação automática de pool de nós automatiza totalmente o provisionamento desse hardware especializado quando as cargas de trabalho exigem. Isso ajuda a garantir que até mesmo as tarefas mais exigentes em termos de computação recebam o hardware necessário quando precisarem.
Para mais informações, consulte Sobre a criação automática de pools de nós.
Para conferir os aceleradores disponíveis no GKE, consulte:
ComputeClasses: o gatilho para a criação automática de pool de nós
Embora a criação automática de pool de nós possa ser acionada por uma solicitação de um pod para um tipo de hardware específico (como nvidia-l4-vws), usar uma ComputeClass é o método mais resiliente e moderno. Uma ComputeClass é um recurso do GKE que você define e que age em um conjunto de regras para controlar e personalizar o escalonamento automático do hardware. Embora não seja um escalonador automático, ele funciona com o escalonador automático de cluster.
Para estender a analogia, pense nas ComputeClasses como um "formulário de solicitação inteligente" para os equipamentos da sua loja.
Em vez de um associado de vendas (seu pod) exigir um hardware específico e rígido (por exemplo, "Preciso da caixa registradora Modelo 500 da Marca X"), ele solicita uma capacidade usando o formulário de requisição (por exemplo, "Preciso de um caixa de alta velocidade"). O formulário, a ComputeClass, contém um conjunto de regras para a equipe de compras (GKE) sobre como atender a esse pedido.
As ComputeClasses separam a solicitação de hardware do pod da ação de provisionamento do GKE. Em vez de exigir uma máquina específica (como a3-highgpu-8g), o pod pode solicitar uma ComputeClass. A ComputeClass define a lógica "inteligente", uma lista priorizada de regras que informa ao GKE como atender a essa solicitação.
Para mais informações, consulte Sobre as ComputeClasses do GKE.
Para uma análise detalhada das ComputeClasses com exemplos reais e configurações YAML, consulte o guia técnico: Otimizar cargas de trabalho do GKE com ComputeClasses personalizadas.
Principais métricas e gatilhos para escalonamento automático
Para tomar decisões de escalonamento fundamentadas, os componentes de escalonamento automático monitoram diferentes indicadores. A tabela a seguir mostra a comparação dos gatilhos de escalonamento automático com base em métricas.
| Componente | Reage a | Origem do indicador | Linha de raciocínio | Ação do GKE |
|---|---|---|---|---|
| HPA | Carga atual | Consumo em tempo real, por exemplo, a CPU está em 90% agora. | "Os pods atuais estão sobrecarregados. Precisamos distribuir esse tráfego imediatamente." | Escalonamento horizontal: muda o número de réplicas de pod para atender à demanda. |
| VPA | Eficiência de dimensionamento | Consumo histórico, por exemplo, uso médio de RAM nas últimas 24 horas. | "As necessidades de recursos deste pod mudaram ou nossas estimativas iniciais estavam incorretas. Precisamos ajustar a alocação de recursos para corresponder ao uso real" | Aumenta ou diminui: muda o tamanho (limites de CPU ou RAM) do pod para ajustar o tamanho dele. |
| Criação automática de pool de nós | Disponibilidade de hardware | Solicitações não atendidas, por exemplo, o pod está no status "Pendente" porque não há nós de GPU. | "Não é possível iniciar este pod porque o hardware físico solicitado está ausente." | Provisiona a infraestrutura: cria novos pools de nós com o hardware específico. |
Gatilhos do escalonador automático horizontal de pods (HPA): reação à carga
O HPA escalona o número de pods (aumenta ou diminui) monitorando as métricas de performance em tempo real. Por exemplo, a utilização de CPU e memória, as métricas fundamentais que indicam a carga de processamento nos seus pods, estão disponíveis imediatamente para o HPA.
No entanto, algumas métricas precisam de configurações explícitas, como:
- Métricas do balanceador de carga (solicitações por segundo, RPS): uma medida direta do tráfego de aplicativos, permitindo respostas de escalonamento mais rápidas. Para usar essa métrica, consulte Ativar o balanceamento de carga baseado em utilização e o perfil de HPA de desempenho.
- Métricas personalizadas: configure o escalonamento automático com base em métricas de negócios personalizadas, como "número de usuários ativos", para gerenciar recursos de forma proativa com base na demanda prevista. Para usar métricas personalizadas, é necessário configurar um pipeline de métricas para expô-las ao HPA. Para mais informações, consulte Google Cloud Managed Service para Prometheus.
Gatilhos do escalonador automático vertical de pods (VPA): reação às necessidades de recursos
O VPA ajusta o tamanho do pod (aumenta ou diminui) monitorando o consumo histórico de recursos:
- Utilização de CPU e memória: o VPA analisa o uso anterior de um pod para determinar se a solicitação de recursos está correta. O objetivo principal do VPA é evitar a disputa de recursos aumentando ou diminuindo as solicitações de memória e CPU de um pod para corresponder às necessidades reais dele.
Gatilhos de criação automática de pool de nós: reação a solicitações de hardware
A criação automática de pools de nós provisiona novos pools com hardware especializado. Ela não é acionada por métricas de performance, como carga da CPU. Em vez disso, ele é acionado por uma solicitação de recurso de um pod:
- Solicitação de recurso não programável: um gatilho principal. Quando um pod é criado, ele solicita hardware específico. Se o cluster não puder atender a essa solicitação porque nenhum nó existente tem esse hardware, a criação automática de pool de nós será acionada.
- Solicitação de ComputeClass: um pod solicita uma ComputeClass, por exemplo,
cloud.google.com/compute-class: premium-gpu. Se nenhum nó no cluster puder fornecer os recursos "premium-gpu", a criação automática de pool de nós vai criar um novo pool que possa fornecer esses recursos.
Para saber como usar métricas personalizadas, do Prometheus e externas para fazer o escalonamento automático, consulte Sobre o escalonamento automático de cargas de trabalho com base em métricas.
Conclusão
Ao aplicar essas estratégias de escalonamento automático, é possível gerenciar com eficiência as cargas de trabalho de IA/ML flutuantes. Assim como o gerente da loja Cymbal Shops navegou pelo evento de pico de vendas gerenciando os recursos de maneira flexível, você pode usar o escalonamento automático do GKE para expandir e reduzir automaticamente os recursos de infraestrutura e de carga de trabalho. Isso ajuda a garantir que os modelos mantenham a performance durante picos de tráfego e sejam econômicos em períodos de baixa atividade, mantendo o ambiente dimensionado corretamente.
A seguir
- Confira uma visão geral das cargas de trabalho de inferência de IA/ML no GKE.
- Saiba como veicular LLMs abertos no GKE com uma arquitetura pré-configurada.
- Saiba como aplicar ComputeClasses aos pods por padrão.