O problema da escalabilidade automática em cargas de GPU pode não ser uma falha do Kubernetes em tomar a decisão, mas o fato de a decisão chegar tarde demais. Ramkumar Nagaraj e Bingi Narasimha Karthik, da Adobe, descrevem um incidente no qual um serviço de produção crítico enfrentou uma onda de demanda que elevou as taxas de erro dos usuários para 15–20%, embora o Horizontal Pod Autoscaler tivesse iniciado a escalabilidade. A causa foi que centenas de contêineres permaneceram aguardando, enquanto os novos nós de GPU precisaram de muito tempo para ficar prontos.
Na sequência documentada pelos autores, a onda de demanda chegou às 06:00, os indicadores do HPA ultrapassaram o limite às 06:05 e o agendamento dos contêineres começou às 06:15. No entanto, os primeiros nós de GPU só concluíram o processo de preparação às 06:45, ou seja, depois do fim da onda de pico. A preparação de nós de GPU normalmente leva de três a cinco vezes mais tempo do que a preparação de serviços baseados em CPU, devido ao carregamento do firmware, à configuração dos drivers e à preparação do CUDA.
Da reação à demanda à preparação para ela
A equipe propôs executar um controlador dentro do Kubernetes a cada 60 segundos, lendo uma hora de métricas anteriores e prevendo a demanda para os dez minutos seguintes. O objetivo não é uma previsão perfeita, mas começar a preparar a capacidade com antecedência suficiente para que os nós e contêineres estejam prontos quando necessário.
O projeto utilizou dados coletados pelo Prometheus, incluindo uso de CPU e memória, tempo de resposta, taxa de solicitações e uso de GPU. A equipe testou os modelos ARIMA, suavização exponencial, a biblioteca Prophet e LSTM, antes de escolher um modelo Bi-LSTM composto por duas camadas com 64 e depois 32 unidades. A escolha ocorreu, segundo o artigo, em resposta a padrões de dados que incluíam picos curtos, períodos de recuperação e valores constantes anômalos, e não porque fosse a melhor opção teórica em todos os casos.
O modelo é retreinado semanalmente, enquanto o modelo implantado funciona apenas no modo de inferência dentro de um binário do controlador escrito em Go, utilizando TensorFlow Lite. Dessa forma, o projeto não precisa de uma plataforma externa de aprendizado de máquina nem de uma camada de serviço de modelos.
Três camadas para controlar a escalabilidade
O projeto baseia-se em três funções interligadas: previsão, preparação e absorção. O modelo prevê a demanda; em seguida, o controlador começa a aumentar gradualmente o número de réplicas, enquanto a capacidade previamente preparada oferece espaço para absorver a onda real.
Como a previsão não consegue lidar com toda surpresa, a equipe acrescentou um detector de picos repentinos que opera em paralelo. Esse componente compara a demanda real com as previsões usando um limite adaptativo baseado no desvio-padrão móvel. Se a demanda ultrapassar a previsão por uma diferença que atinja o nível de confiança definido, o detector aumenta a velocidade da escalabilidade. Os autores descrevem esse componente como uma rede de segurança baseada em regras, não como um segundo modelo preditivo.
Já o escalonador gradual limita o aumento a 20 contêineres por minuto. O objetivo é evitar uma onda maciça de agendamento que pressione o agendador e o etcd e provoque congestionamento nas operações de extração de imagens, inicialização de contêineres, preparação de contêineres init e injeção de sidecars. O uso-alvo também foi definido em 70%, em vez de 100%, para deixar uma margem que permita absorver picos e manter o modelo mesmo quando ocasionalmente impreciso, sem transformar o erro em uma cadeia de falhas.
O que os testes demonstraram?
A equipe executou inicialmente o sistema em modo sombra, registrando as previsões sem realizar uma escalabilidade efetiva, e coletou mais de 500 horas de dados. Os resultados mostraram precisão de 85% quando a previsão da demanda para dez minutos depois ficou dentro de uma margem de ±10% da demanda real. O detector de picos também identificou nove de dez ondas, com dois falsos positivos, enquanto os testes do escalonador gradual não apresentaram falhas em cascata nem oscilação na escalabilidade.
O sistema também operou ao lado do HPA v2 sem conflitos. Durante uma semana de validação em um ambiente de desenvolvimento controlado, passou em 23 de 23 testes. Em uma simulação dos padrões de pico que causaram o incidente original, o sistema conseguiu detectar a onda cerca de 11 minutos antes.
Quando essa abordagem é adequada?
A escalabilidade preditiva mostra seu valor quando a preparação dos nós leva mais de dois ou três minutos e quando a demanda é parcialmente previsível, como em padrões diários ou semanais ou em eventos conhecidos. Ela também exige bons dados de monitoramento, com pelo menos uma semana de métricas do Prometheus. Por outro lado, a ideia se torna menos útil se os nós forem preparados em 30 segundos, se a demanda for completamente aleatória ou se a prioridade da equipe for reduzir custos acima de tudo; manter nós aquecidos significa pagar pelo excesso de capacidade.
Leitura editorial: a mudança prática aqui não é substituir o HPA, mas acrescentar tempo de previsão a um sistema que normalmente lida com a demanda depois que ela aparece. Sua importância está especificamente nas cargas de GPU, nas quais a velocidade da decisão de escalabilidade não é suficiente se a infraestrutura precisa de dezenas de minutos antes de iniciar os contêineres. No entanto, as evidências apresentadas ainda resultam de uma validação controlada, e não de uma medição independente e ampla em vários ambientes de produção.
A própria experiência da equipe aponta limitações importantes: um modelo ARIMA ajustado pode alcançar um resultado próximo com uma arquitetura mais simples, e o modelo pode ficar desatualizado em poucos dias quando os padrões de demanda mudam. A explicação sobre o motivo de o sistema prever determinado número de réplicas também continuou difícil, e ainda não foram resolvidas questões relativas ao tamanho ideal dos dados, à periodicidade do retreinamento e à capacidade do detector de picos baseado em regras de identificar eventos sem precedentes.
Por isso, o artigo recomenda começar coletando uma semana de métricas, treinando um modelo simples, executando-o em modo sombra e medindo a precisão antes de ativar a escalabilidade. Ao passar para a produção, deve-se impor um limite máximo de réplicas, disponibilizar um procedimento claro de desativação e, de preferência, passar por uma etapa de escalabilidade restrita antes de liberar o uso completo. A conclusão repetida pelos autores é prática: a complexidade do modelo não é uma vantagem por si só; se a solução mais simples funcionar, é melhor utilizá-la.