KEDA no Node.js

O KEDA no Node.js escala Deployments, StatefulSets e Jobs do Kubernetes a partir de eventos externos, como quantidade de mensagens, lag de consumidores, métricas Prometheus e profundidade de filas. Em vez de depender apenas de CPU e memória, a aplicação reage à demanda real do trabalho pendente.

KEDA funciona junto com o Horizontal Pod Autoscaler. Ele coleta métricas por meio de scalers e cria ou gerencia os recursos necessários para ajustar réplicas. Uma configuração ruim pode causar flapping, excesso de consumidores, custo elevado ou sobrecarga em bancos e brokers.

Neste guia, você aprenderá ScaledObject, ScaledJob, TriggerAuthentication, scale-to-zero, cooldown, fallback, RabbitMQ, Kafka, Redis, Prometheus e práticas para workers Node.js.

O que é KEDA?

A documentação oficial dos conceitos do KEDA descreve três componentes principais:

• Operator: observa recursos e controla escala de zero para um.
• Metrics Server: expõe external metrics para o HPA.
• Scalers: consultam filas, bancos, APIs e plataformas.

KEDA adiciona recursos sem substituir o HPA nativo.

Quando usar KEDA?

• Workers consumindo RabbitMQ, Kafka, Redis ou SQS.
• Jobs disparados por eventos.
• Aplicações que podem escalar até zero.
• Serviços guiados por métricas Prometheus.
• Cargas em que CPU não representa backlog.

Para APIs HTTP, CPU, concorrência e request rate podem continuar mais adequados.

Instalação

Instale por Helm com versão fixada:

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm upgrade --install keda kedacore/keda \
  --namespace keda \
  --create-namespace \
  --version 2.18.2

Confirme a versão atual e a compatibilidade do cluster. Veja Helm para Node.js.

Worker Node.js

Um worker RabbitMQ pode controlar prefetch e shutdown:

const channel = await connection.createChannel();
await channel.prefetch(10);

await channel.consume('invoices', async message => {
  if (!message) return;

  try {
    await processInvoice(JSON.parse(message.content.toString()));
    channel.ack(message);
  } catch (error) {
    channel.nack(message, false, shouldRetry(error));
  }
});

A concorrência por Pod precisa ser conhecida para transformar mensagens pendentes em réplicas.

ScaledObject básico

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: invoice-worker
  namespace: production
spec:
  scaleTargetRef:
    name: invoice-worker
  minReplicaCount: 0
  maxReplicaCount: 30
  pollingInterval: 15
  cooldownPeriod: 300
  triggers:
    - type: rabbitmq
      metadata:
        protocol: amqp
        queueName: invoices
        mode: QueueLength
        value: "50"
      authenticationRef:
        name: rabbitmq-auth

O alvo é um Deployment chamado invoice-worker. A meta tenta manter aproximadamente cinquenta mensagens por réplica.

TriggerAuthentication

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-auth
  namespace: production
spec:
  secretTargetRef:
    - parameter: host
      name: rabbitmq-credentials
      key: host

O Secret contém a URL. Para cloud providers, prefira workload identity em vez de credenciais estáticas.

Scale-to-zero

Com minReplicaCount: 0, o Operator pode reduzir o Deployment a zero. Quando a métrica fica ativa, ele escala para um e o HPA assume o restante.

Scale-to-zero economiza recursos, mas adiciona cold start. Não use quando o primeiro job possui deadline curto ou quando o worker demora para iniciar.

Idle replica count

Algumas versões permitem configurar réplicas ociosas abaixo do mínimo de atividade. Verifique as limitações documentadas e teste interação com HPA.

Polling interval

pollingInterval: 15

Quando o workload está em zero, KEDA consulta a fonte nesse intervalo. Um valor curto reduz reação, mas aumenta chamadas à fila ou API.

Cooldown period

cooldownPeriod: 300

Após o último evento, KEDA espera antes de reduzir a zero. Isso evita iniciar e parar Workers continuamente.

Comportamento do HPA

advanced:
  horizontalPodAutoscalerConfig:
    behavior:
      scaleUp:
        stabilizationWindowSeconds: 0
        policies:
          - type: Percent
            value: 100
            periodSeconds: 60
      scaleDown:
        stabilizationWindowSeconds: 300
        policies:
          - type: Percent
            value: 25
            periodSeconds: 60

Scale-up rápido reduz backlog. Scale-down lento preserva workers durante oscilações.

KEDA e HPA

Não crie manualmente outro HPA para o mesmo Deployment. KEDA gera e gerencia o HPA. Dois controladores disputando replicas causam comportamento imprevisível.

Consulte Kubernetes HPA no Node.js.

Scaler RabbitMQ

Queue length representa mensagens prontas. Considere também mensagens unacked, duração média e prefetch. Se cada Pod processa dez jobs simultaneamente, uma meta de cinquenta pode significar cinco ciclos de trabalho por Pod.

Scaler Kafka

triggers:
  - type: kafka
    metadata:
      bootstrapServers: kafka:9092
      consumerGroup: invoice-workers
      topic: invoices
      lagThreshold: "100"
      offsetResetPolicy: latest

A quantidade de réplicas úteis é limitada por partições. Criar trinta Pods para um tópico com seis partições deixa vinte e quatro ociosos.

Lag e poison messages

Uma mensagem que falha continuamente mantém lag alto e provoca escala sem aumentar throughput. Configure retries limitados, DLQ e idempotência.

Scaler Redis

KEDA oferece scalers para listas e streams, inclusive variantes para Cluster e Sentinel. A métrica deve corresponder ao modelo de consumo. Veja Redis Cluster no Node.js e Redis Sentinel no Node.js.

Scaler Prometheus

triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring:9090
      metricName: pending_exports
      query: sum(exports_pending{service="export-worker"})
      threshold: "20"

A query deve retornar um único valor numérico. Proteja o endpoint Prometheus e controle labels.

Múltiplos triggers

triggers:
  - type: rabbitmq
    metadata: ...
  - type: prometheus
    metadata: ...

Por padrão, o HPA escolhe a recomendação mais alta entre métricas. Isso protege contra uma fonte que detecta mais demanda.

Scaling modifiers

Versões recentes permitem fórmulas para combinar métricas. Use somente com testes, pois uma expressão errada pode escalar a zero durante backlog.

Fallback

fallback:
  failureThreshold: 3
  replicas: 5

Se o scaler falha repetidamente, KEDA usa uma quantidade fixa. O fallback evita zero por falta de métrica, mas cinco réplicas podem ser insuficientes ou excessivas. Monitore sua ativação.

Initial cooldown

O período inicial pode impedir redução imediata após criação ou restart. Verifique suporte na versão e use quando o serviço precisa aquecer.

ScaledJob

apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
  name: video-transcoder
spec:
  jobTargetRef:
    template:
      spec:
        restartPolicy: Never
        containers:
          - name: worker
            image: registry.example.com/transcoder@sha256:abc123
  maxReplicaCount: 20
  triggers:
    - type: rabbitmq
      metadata:
        queueName: videos
        value: "1"

ScaledJob cria Jobs conforme demanda. É adequado a trabalho isolado que termina, mas não a consumidores persistentes.

ScaledObject ou ScaledJob?

• ScaledObject: Worker contínuo, conexão persistente e vários jobs.
• ScaledJob: um ou poucos itens por Pod, processo termina.

Concorrência e meta

Uma fórmula inicial:

réplicas = ceil(
  backlog × duração média
  / (concorrência por Pod × prazo de drenagem)
)

Ajuste com testes de carga e percentis, não apenas média.

Banco de dados

Mais Workers abrem mais conexões. Se cada Pod possui pool de dez e KEDA escala a trinta, o banco pode receber trezentas conexões. Use limites e PgBouncer. Veja PgBouncer no Node.js.

Rate limits externos

Não escale acima da capacidade do provedor. Configure rate limit global, concorrência por Pod e maxReplicaCount. Um backlog alto causado por 429 não será resolvido com mais Workers.

Graceful shutdown

Durante scale-down, o Pod recebe SIGTERM. O Worker deve parar de buscar mensagens, concluir jobs ativos e fechar conexões. Veja Graceful Shutdown no Node.js.

Visibility timeout e ACK

A mensagem precisa voltar à fila se o Pod morrer. Configure visibility timeout ou ACK conforme o broker. Jobs longos precisam renovar lease ou heartbeat.

PodDisruptionBudget

Use PDB para manutenção, mas não impeça scale-down normal. O PDB protege evictions voluntárias, não alteração de replicas pelo HPA. Consulte PodDisruptionBudget no Node.js.

Autenticação

TriggerAuthentication pode usar Secret, environment, Vault e identidades cloud. Prefira tokens curtos e permissões somente de leitura de métricas ou filas.

ClusterTriggerAuthentication

Reutiliza autenticação entre namespaces. Isso aumenta alcance; restrinja quem pode referenciá-la e evite uma credencial global ampla.

Observabilidade

Monitore:

• réplicas atuais e desejadas;
• métrica do scaler;
• backlog e idade do item mais antigo;
• tempo até scale-up;
• cold start;
• fallback ativo;
• erros de autenticação;
• duração e falhas dos jobs;
• recursos e conexões por Pod.

Diagnóstico

kubectl get scaledobjects -n production
kubectl describe scaledobject invoice-worker -n production
kubectl get hpa -n production
kubectl logs -n keda deployment/keda-operator
kubectl logs -n keda deployment/keda-operator-metrics-apiserver

Teste de escala

1. deixe a fila vazia;
2. confirme scale-to-zero;
3. publique mensagens;
4. meça tempo até o primeiro Pod Ready;
5. observe crescimento de réplicas;
6. confirme drenagem do backlog;
7. pare a publicação;
8. observe cooldown e scale-down.

Erros comuns

• Meta sem considerar concorrência: réplicas ficam excessivas.
• Mais réplicas que partições: consumers permanecem ociosos.
• Scale-to-zero com cold start longo: primeiro job perde deadline.
• Sem DLQ: poison message mantém lag alto.
• Fallback não monitorado: escala fixa permanece por horas.
• Credencial em metadata: Secret vaza no manifesto.
• Dois HPAs: controladores disputam replicas.
• Banco ignorado: autoscaling esgota conexões.

Conclusão

O KEDA no Node.js conecta workloads Kubernetes a filas e métricas externas. ScaledObject e ScaledJob permitem escalar por backlog, lag ou demanda real, inclusive até zero.

Defina metas a partir de concorrência e duração, limite max replicas e proteja dependências. Configure autenticação, fallback e graceful shutdown, e monitore idade da fila. Assim, KEDA reduz recursos ociosos sem transformar cada pico em uma tempestade contra o banco ou broker.