KEDA: escalabilidade baseada em eventos

O que é KEDA e por que o HPA não é suficiente para eventos

Scaling baseado no que realmente importa — a fila de trabalho pendente

KEDA (Kubernetes Event-Driven Autoscaling) é um componente open source que estende o Kubernetes com scaling baseado em eventos e métricas externas. O HPA padrão scala com base em CPU, memória e custom metrics de pods — mas para workers que processam filas de mensagens, a métrica correta de scaling não é o quanto o pod está usando de CPU, é quantas mensagens estão esperando na fila. Um worker com zero mensagens para processar deve ter zero pods rodando (scale-to-zero); um worker com 10.000 mensagens acumuladas deve ter dezenas de pods em paralelo. O KEDA implementa essa lógica de forma nativa, integrando com mais de 50 event sources diferentes — SQS, Kafka, RabbitMQ, Azure Service Bus, Google Pub/Sub, Redis Streams, banco de dados, HTTP, e muito mais — sem exigir que o desenvolvedor implemente métricas customizadas no Prometheus.

Scalers — conectores para filas, bancos e APIs externas

O ecossistema de integrações que torna o KEDA versátil

Scalers são os conectores do KEDA com fontes de eventos externas — cada scaler sabe como consultar a fonte, obter a métrica relevante (número de mensagens, consumer lag, registros pendentes) e disponibilizá-la para o controlador de scaling. O KEDA inclui scalers oficiais para AWS SQS (mensagens na fila), Kafka (consumer lag por group e topic), RabbitMQ (mensagens prontas no queue), Redis (comprimento de lista), PostgreSQL (resultado de query SQL), Prometheus (qualquer query PromQL), HTTP (requisições por segundo via keda-http-add-on), Cron (scaling programado por horário) e dezenas de outros. Cada scaler tem seus próprios parâmetros de configuração — o scaler SQS precisa do nome da fila e da região AWS; o scaler Kafka precisa do bootstrap server, consumer group e nome do tópico. Scalers customizados podem ser criados usando a interface de External Scaler para integrar com qualquer fonte de dados.

ScaledObject — configurando scaling por fila

O recurso Kubernetes que conecta KEDA ao seu deployment

ScaledObject é o recurso customizado (CRD) que define como o KEDA deve escalar um deployment ou statefulset. Ele especifica o target (qual Deployment ou StatefulSet escalar), minReplicaCount (mínimo de réplicas — pode ser zero para scale-to-zero), maxReplicaCount (máximo de réplicas), cooldownPeriod (tempo de espera antes de scale-to-zero após a fila esvaziar), e uma lista de triggers (cada um sendo um scaler com seus parâmetros). O KEDA cria automaticamente um HPA para gerenciar o número de réplicas — o ScaledObject controla o HPA, não os pods diretamente. Quando múltiplos triggers são definidos, o KEDA scala baseado no trigger que exige o maior número de réplicas — garantindo que o deployment está dimensionado para a demanda mais alta de qualquer uma das fontes de eventos monitoradas.

Scale to zero — economizando recursos quando não há eventos

O diferencial do KEDA versus o HPA padrão do Kubernetes

Scale-to-zero é a capacidade de reduzir o número de réplicas para zero quando não há eventos a processar — o HPA padrão não consegue fazer isso porque exigiria pods rodando para fornecer métricas. O KEDA resolve isso sendo o próprio provedor de métricas externas: ele consulta a fonte de eventos diretamente (a fila SQS, o tópico Kafka) sem depender de métricas dos pods. Com minReplicaCount igual a zero, quando a fila está vazia por mais tempo que o cooldownPeriod configurado, o KEDA reduz o deployment para zero réplicas — zero custo, zero recursos consumidos. Quando uma nova mensagem chega na fila, o KEDA detecta na próxima varredura (pollInterval, padrão 30 segundos) e escala o deployment para pelo menos uma réplica para iniciar o processamento. O cold start do primeiro pod é o principal tradeoff do scale-to-zero — para filas onde latência de processamento importa, mantenha minReplicaCount igual a 1.

KEDA com SQS — scaling por número de mensagens na fila

Configuração prática para workers de processamento na AWS

O scaler SQS do KEDA consulta o atributo ApproximateNumberOfMessages da fila para determinar quantas mensagens estão aguardando processamento. A configuração do trigger especifica queueURL (URL completo da fila SQS), queueLength (número de mensagens por réplica — se for 100, o KEDA cria uma réplica por 100 mensagens na fila), e awsRegion. A autenticação com a AWS usa TriggerAuthentication — um objeto KEDA que referencia um Secret Kubernetes com as credenciais, ou IAM Roles for Service Accounts (IRSA) para autenticação sem credenciais de longa duração. Com IRSA, o service account do pod assume um IAM Role que tem permissão sqs:GetQueueAttributes, sem necessidade de access keys estáticas. Um worker que processa 1 mensagem por segundo com SLA de 10 segundos de latência máxima deveria ter queueLength configurado como 10 — garantindo que o lag nunca excede 10 vezes a taxa de processamento por pod.

KEDA com Kafka — scaling por lag do consumer group

Processamento de streams com scaling proporcional ao atraso acumulado

O scaler Kafka do KEDA usa o consumer group lag — a diferença entre o offset mais recente produzido e o offset mais recente consumido por partição — como métrica de scaling. Quando o lag cresce, o KEDA adiciona consumers; quando o lag se aproxima de zero, reduz. A configuração especifica bootstrapServers (endereço do cluster Kafka), consumerGroup (nome do consumer group monitorado), topic (nome do tópico) e lagThreshold (lag por réplica que dispara scaling — se lagThreshold é 100, o KEDA cria uma réplica por 100 mensagens de lag). O número máximo de réplicas não deve exceder o número de partições do tópico — consumers adicionais além do número de partições ficam ociosos, pois Kafka não distribui uma partição entre múltiplos consumers do mesmo grupo. Um deployment Kafka-driven bem configurado escala de 0 a N réplicas (onde N é o número de partições) com base no lag acumulado.

KEDA com RabbitMQ e HTTP

Cobrindo filas AMQP e tráfego HTTP com o mesmo mecanismo

O scaler RabbitMQ do KEDA monitora o número de mensagens prontas (ready messages) em uma queue via a Management API do RabbitMQ. A autenticação usa um Secret com as credenciais de acesso à Management API, e a configuração especifica host (URL da API com protocolo amqp ou http), queueName e mode (QueueLength para mensagens absolutas ou MessageRate para taxa por segundo). Para HTTP, o keda-http-add-on é um addon separado que intercepta requisições HTTP, as enfileira em um buffer interno, e escala o deployment baseado na profundidade desse buffer — permitindo scale-to-zero para APIs HTTP com tráfego intermitente. O add-on HTTP usa um proxy que garante que requisições não sejam perdidas durante o cold start do primeiro pod — elas ficam no buffer e são entregues quando o pod fica pronto. Essa abordagem é especialmente útil para backends de aplicações com tráfego concentrado em horários específicos.

Autenticação e segredos no KEDA

Gerenciando credenciais de fontes externas de forma segura

KEDA usa o recurso TriggerAuthentication para gerenciar credenciais usadas pelos scalers para acessar fontes de eventos. Um TriggerAuthentication pode referenciar um Secret Kubernetes, variáveis de ambiente de um pod, ou serviços externos como HashiCorp Vault e Azure Key Vault. Para AWS, a integração com IRSA (IAM Roles for Service Accounts) elimina credenciais de longa duração: o service account do KEDA assume um IAM Role que tem permissões mínimas de leitura nas filas SQS ou tópicos Kafka. ClusterTriggerAuthentication é similar ao TriggerAuthentication mas com escopo de cluster — pode ser compartilhado entre múltiplos ScaledObjects em diferentes namespaces, centralizando o gerenciamento de credenciais compartilhadas como as credenciais do cluster Kafka. Rotação de credenciais é automática quando o Secret Kubernetes é atualizado — o KEDA usa sempre o valor atual do Secret sem necessidade de restart.

KEDA em produção — limites e boas práticas

O que aprender antes de colocar KEDA em sistemas críticos

Em produção, alguns aspectos do KEDA requerem atenção especial. O pollInterval (padrão 30 segundos) determina a frequência com que o KEDA consulta a fonte de eventos — valores menores aumentam a responsividade mas também o número de chamadas à API externa (com implicações de custo para SQS, por exemplo). O cooldownPeriod (padrão 300 segundos) controla quanto tempo após a fila esvaziar o KEDA aguarda antes de scale-to-zero — muito curto causa thrashing entre 0 e 1 réplica para filas com mensagens intermitentes. Limite o maxReplicaCount considerando a capacidade do banco de dados ou serviços downstream que os workers acessam — 100 workers simultâneos consultando um banco com limite de 100 conexões resultará em erros de conexão. Monitore o KEDA com as métricas Prometheus que ele expõe nativamente — keda_scaler_metrics_value (valor atual da métrica), keda_scaler_errors_total (erros de consulta aos scalers) e keda_scaled_object_errors_total (erros de reconciliação).

Conclusão — KEDA como evolução natural do auto-scaling orientado a eventos

Da reatividade de CPU para a precisão de eventos reais de negócio

KEDA representa a evolução do scaling no Kubernetes de métricas de infraestrutura para métricas de negócio reais — escalar pelo número de pedidos pendentes de processamento é semanticamente mais correto do que escalar pela CPU dos workers. Scale-to-zero elimina custos em workloads intermitentes sem sacrificar a capacidade de resposta quando eventos chegam. Com mais de 50 scalers oficiais e suporte a scalers customizados, KEDA cobre praticamente qualquer fonte de eventos que um sistema moderno possa usar. Integrado com HPA, Kubernetes nativo e um ecossistema rico de ferramentas de observabilidade, o KEDA é hoje o padrão de fato para scaling orientado a eventos no Kubernetes. Continue em: Fundamentos obrigatórios antes de produção.