KEDA no Kubernetes: guia completo para iniciantes

Guilherme Miguel

10 min read

·

3 days ago

--

Share

O que é, para que serve, como funciona e como configurar o escalonamento automático de aplicações

1. Introdução

Quando trabalhamos com Kubernetes, uma das principais preocupações é garantir que nossas aplicações tenham recursos suficientes para atender à demanda dos usuários.

Imagine uma aplicação que consome mensagens de uma fila do AWS SQS, Kafka ou RabbitMQ.

Durante a maior parte do dia, ela recebe poucas mensagens. Entretanto, em determinados horários, o volume de mensagens aumenta significativamente.

Nesse cenário, temos dois problemas:

• Se mantivermos muitas réplicas da aplicação, consumiremos recursos computacionais desnecessariamente.
• Se mantivermos poucas réplicas, poderemos acumular mensagens na fila e aumentar o tempo de processamento.

O Kubernetes possui um mecanismo nativo chamado HPA (Horizontal Pod Autoscaler), responsável por aumentar ou diminuir a quantidade de Pods de acordo com determinadas métricas.

Entretanto, existe uma ferramenta que amplia bastante essa capacidade: o KEDA (Kubernetes Event-driven Autoscaling).

O KEDA permite que aplicações sejam escaladas automaticamente com base em eventos externos, como quantidade de mensagens em filas, eventos do Kafka, métricas de bancos de dados e diversas outras fontes.

Neste artigo, vamos entender como ele funciona e construir uma configuração prática, começando do zero.

Press enter or click to view image in full size

O KEDA (Kubernetes Event-driven Autoscaling) é um componente open source que permite realizar o escalonamento automático de aplicações Kubernetes com base em eventos e métricas externas.

Em termos simples, ele permite que você diga ao Kubernetes:

“Quero que minha aplicação tenha mais Pods quando houver muitas mensagens na fila e que reduza a quantidade de Pods quando a fila estiver vazia.”

Isso é especialmente interessante para aplicações que trabalham com processamento assíncrono, consumidores de filas e arquiteturas orientadas a eventos.

O KEDA trabalha integrado aos mecanismos nativos do Kubernetes, principalmente o HPA.

Uma característica muito importante: o KEDA também permite que uma aplicação seja escalada até zero réplicas, quando configurada para isso. Assim, podemos manter um consumidor completamente parado quando não existem eventos para processar e iniciá-lo automaticamente quando surgir demanda.

3. Como o KEDA funciona?

Para entender o funcionamento, precisamos conhecer três componentes importantes.

3.1. KEDA Operator

É o componente responsável por monitorar as configurações de escalabilidade e verificar as fontes externas de eventos.

Por exemplo:

• Consultar a quantidade de mensagens em uma fila SQS.
• Verificar o lag de um tópico Kafka.
• Consultar o tamanho de uma fila RabbitMQ.
• Avaliar métricas disponibilizadas por Prometheus.

Quando identifica a necessidade de ativar ou desativar uma aplicação, o Operator participa do processo de escalabilidade.

Isso significa que você não precisa desenvolver uma integração própria para cada serviço que deseja monitorar, desde que exista um Scaler compatível.

3.3. Horizontal Pod Autoscaler (HPA)

O HPA é o mecanismo nativo do Kubernetes responsável por ajustar a quantidade de réplicas de uma aplicação.

O KEDA trabalha em conjunto com ele.

Uma maneira simples de entender essa relação é:

• KEDA monitora os eventos externos.
• KEDA disponibiliza métricas para o Kubernetes.
• HPA utiliza essas métricas para ajustar a quantidade de Pods.
• Kubernetes cria ou remove os Pods conforme necessário.

Quando não existem eventos, o KEDA também pode controlar a redução da aplicação até zero réplicas.

3.4. Entendendo o fluxo na prática

Imagine uma aplicação que consome mensagens de uma fila SQS.

O fluxo seria:

1. Uma mensagem chega na fila SQS.
2. O KEDA consulta a quantidade de mensagens pendentes.
3. O KEDA identifica que existe demanda para processamento.
4. O Kubernetes inicia os Pods consumidores.
5. O HPA aumenta a quantidade de réplicas conforme a métrica configurada.
6. Os consumidores processam as mensagens.
7. Quando a fila diminui, a quantidade de Pods também diminui.
8. Se a fila ficar vazia, a aplicação poderá chegar a zero réplicas.

É importante entender que o KEDA não consome as mensagens. Quem faz isso é a sua aplicação. O KEDA apenas monitora a fonte de eventos e controla o escalonamento.

4. Principais recursos do KEDA

Antes de configurar nossa primeira aplicação, precisamos conhecer alguns conceitos importantes.

4.1. ScaledObject

O ScaledObject é um dos principais recursos do KEDA.

Ele define:

• Qual aplicação será escalada.
• Qual fonte de eventos será monitorada.
• Qual será o número mínimo de réplicas.
• Qual será o número máximo de réplicas.
• Qual métrica será utilizada como referência para escalabilidade.

Exemplo simplificado:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: meu-consumer-scaler
spec:
  scaleTargetRef:
    name: meu-consumer

  minReplicaCount: 0
  maxReplicaCount: 10

  triggers:
    - type: rabbitmq
      metadata:
        queueName: pedidos

Nesse exemplo, estamos dizendo ao KEDA que ele deverá monitorar uma fila RabbitMQ e controlar as réplicas da aplicação meu-consumer.

4.2. ScaledJob

O ScaledJob é utilizado quando queremos criar Kubernetes Jobs conforme a quantidade de eventos disponíveis.

Imagine um sistema que precisa processar arquivos enviados pelos usuários.

Em vez de manter consumidores executando continuamente, podemos criar Jobs sob demanda.

Cada Job executa um processamento e termina quando conclui sua tarefa.

A diferença principal é:

• ScaledObject: escala aplicações que normalmente ficam executando continuamente, como Deployments.
• ScaledJob: cria Jobs para executar trabalhos sob demanda.

4.3. TriggerAuthentication

Muitas fontes de eventos exigem autenticação.

Por exemplo, para consultar uma fila AWS SQS, precisamos que o KEDA tenha autorização para acessar a AWS.

O TriggerAuthentication permite configurar essas credenciais e mecanismos de autenticação separadamente do ScaledObject.

Isso facilita a reutilização e a administração das credenciais.

4.4. ClusterTriggerAuthentication

É semelhante ao TriggerAuthentication, mas permite compartilhar configurações de autenticação entre diferentes namespaces do cluster.

É bastante útil em ambientes com várias aplicações e equipes.

5. Instalando o KEDA no Kubernetes

Agora vamos colocar a teoria em prática.

Para este exemplo, vamos considerar que você já possui:

• Um cluster Kubernetes funcionando.
• kubectl instalado e configurado.
• Helm instalado.

O Helm é um gerenciador de pacotes para Kubernetes que facilita a instalação e atualização de componentes.

Passo 1: Adicionar o repositório Helm

Execute:

helm repo add kedacore https://kedacore.github.io/charts

//Atualize os repositórios
helm repo update

Passo 2: Instalar o KEDA

Execute:

helm install keda kedacore/keda \
  --namespace keda \
  --create-namespace

Esse comando instala os componentes do KEDA no namespace keda.

Passo 3: Verificar a instalação

Execute:

kubectl get pods -n keda

Se a instalação estiver funcionando, você verá recursos como scaledobjects.keda.sh e scaledjobs.keda.sh.

“KEDA instalado”

A partir desse momento, seu cluster está preparado para receber configurações de escalabilidade baseadas em eventos.

6. Configurando o primeiro autoscaling com AWS SQS

Vamos utilizar um cenário bastante comum em arquiteturas distribuídas.

Imagine a seguinte arquitetura:

Temos:

• Uma aplicação produtora que envia mensagens.
• Uma fila AWS SQS.
• Uma aplicação Consumer executando no Kubernetes.
• KEDA monitorando a fila.
• Kubernetes aumentando ou diminuindo os consumidores.

Imagine que temos uma fila chamada pedidos.

Nosso objetivo será:

• Iniciar com zero Pods consumidores.
• Criar consumidores quando existirem mensagens.
• Aumentar até 10 Pods.
• Reduzir os consumidores quando a fila estiver vazia.

Passo 1: Criar o Deployment

Primeiro, precisamos ter uma aplicação executando no Kubernetes.

Exemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pedido-consumer
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pedido-consumer
  template:
    metadata:
      labels:
        app: pedido-consumer
    spec:
      containers:
        - name: consumer
          image: minha-imagem-consumer:1.0
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi

Observe que estamos criando um Deployment chamado pedido-consumer.

Esse será o alvo do nosso escalonamento.

Em um ambiente real, essa imagem deverá conter uma aplicação que efetivamente consome mensagens da fila SQS.

Passo 2: Configurar a autenticação AWS

O KEDA precisa consultar a fila SQS para descobrir quantas mensagens estão pendentes.

Em um cluster EKS, uma boa abordagem é utilizar identidade de workload, como EKS Pod Identity ou IRSA, evitando armazenar Access Keys diretamente nos arquivos YAML.

Exemplo de configuração com identidade AWS:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: aws-trigger-auth
  namespace: default
spec:
  podIdentity:
    provider: aws

ssa configuração permite utilizar a identidade AWS configurada para o KEDA Operator.

Atenção: não basta criar esse YAML. É necessário configurar a identidade no EKS e conceder ao IAM Role as permissões necessárias para consultar a fila, especialmente sqs:GetQueueAttributes.

Passo 3: Criar o ScaledObject

Agora vem a parte mais importante.

Vamos criar o recurso responsável por conectar nossa aplicação à fila SQS.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: pedido-consumer-scaler
  namespace: default
spec:
  scaleTargetRef:
    name: pedido-consumer

  pollingInterval: 15
  cooldownPeriod: 60

  minReplicaCount: 0
  maxReplicaCount: 10

  triggers:
    - type: aws-sqs-queue
      authenticationRef:
        name: aws-trigger-auth
      metadata:
        queueURL: "https://sqs.us-east-1.amazonaws.com/123456789012/pedidos"
        awsRegion: "us-east-1"
        queueLength: "10"

Vamos entender as principais propriedades:

Neste exemplo, estamos configurando uma referência de 10 mensagens por réplica.

De forma simplificada, se houver 100 mensagens pendentes, o KEDA poderá solicitar aproximadamente 10 réplicas, respeitando os limites e o algoritmo de escalonamento do HPA.

A quantidade real também dependerá das métricas observadas, da configuração e do comportamento do HPA.

Passo 4: Aplicar as configurações

Salve os arquivos YAML e execute:

kubectl apply -f deployment.yaml

kubectl apply -f trigger-authentication.yaml

kubectl apply -f scaled-object.yaml

//Verifique o ScaledObject:
kubectl get scaledobjects

//Verifique o HPA criado pelo KEDA:
kubectl get hpa

//E acompanhe os Pods:
kubectl get pods -w

Agora você poderá observar a quantidade de réplicas aumentando ou diminuindo conforme a demanda da fila.

Observação importante: o exemplo de autenticação pressupõe que a identidade AWS foi configurada corretamente para o KEDA Operator. Se optar por identidade vinculada ao Pod consumidor, a configuração será diferente. Também é necessário garantir que a aplicação consiga acessar a fila e tenha suas próprias permissões de consumo.

7. Como testar o escalonamento?

Depois de aplicar as configurações, podemos simular o comportamento da aplicação.

Imagine os seguintes cenários:

Para acompanhar o comportamento em tempo real, utilize:

kubectl get pods -w

//Para verificar o comportamento do KEDA:
kubectl describe scaledobject pedido-consumer-scaler

//Para verificar os logs do Operator:
kubectl logs deployment/keda-operator -n keda

//Você também pode consultar as métricas do HPA:
kubectl describe hpa

8. KEDA versus HPA: qual a diferença?

Essa é uma das dúvidas mais comuns de quem está começando a trabalhar com KEDA.

O HPA já existe nativamente no Kubernetes. Então, por que precisamos do KEDA?

A resposta está nas fontes de métricas utilizadas.

O KEDA não substitui o HPA. Ele complementa o mecanismo de escalabilidade do Kubernetes.

Inclusive, quando você cria um ScaledObject, o KEDA normalmente cria e gerencia um HPA associado à aplicação.

9. Quando utilizar KEDA?

O KEDA é especialmente interessante em arquiteturas que utilizam processamento assíncrono.

Alguns exemplos práticos:

1. Processamento de pedidos

Uma aplicação recebe pedidos e publica mensagens no SQS. Os consumidores aumentam conforme o volume de pedidos.

2. Processamento de arquivos

Uma aplicação recebe arquivos e coloca os identificadores em uma fila. O KEDA aumenta a quantidade de Workers conforme a quantidade de arquivos pendentes.

3. Arquitetura baseada em Kafka

Uma aplicação consome eventos de um tópico Kafka. O KEDA pode utilizar o Consumer Lag para ajustar a quantidade de consumidores.

4. Processamento de notificações

Uma aplicação envia e-mails, SMS ou notificações utilizando uma fila. A quantidade de consumidores aumenta conforme a demanda.

5. Processamentos agendados

Uma aplicação precisa executar mais réplicas em horários específicos. Podemos utilizar o Scaler Cron para controlar esse comportamento.

10. Boas práticas ao utilizar KEDA em produção

Alguns cuidados são importantes para evitar problemas em ambientes produtivos.

• Defina limites de escalabilidade: configure minReplicaCount e maxReplicaCount de acordo com a capacidade do cluster e da aplicação.
• Configure corretamente os recursos: utilize CPU e memória adequadas para cada Pod.
• Cuide da autenticação: prefira IAM Roles, Workload Identity e mecanismos de identidade em vez de credenciais fixas.
• Monitore as filas: acompanhe quantidade de mensagens, tempo de espera e falhas de processamento.
• Evite escalabilidade excessiva: considere a capacidade do banco de dados e dos serviços downstream.
• Configure o encerramento gracioso: seus consumidores precisam terminar ou liberar o processamento das mensagens antes de serem finalizados.
• Atenção ao scale-to-zero: considere o tempo necessário para inicializar a aplicação quando uma nova mensagem chegar.

Um detalhe importante: escalar de zero não significa processamento instantâneo. Existe um intervalo entre a chegada do evento, a detecção pelo KEDA, a criação do Pod e a inicialização da aplicação.

11. Conclusão

O KEDA é uma ferramenta extremamente interessante para quem trabalha com Kubernetes e arquiteturas distribuídas.

Ele permite construir aplicações mais eficientes, reduzindo o consumo de recursos quando não existe demanda e aumentando automaticamente a capacidade de processamento quando necessário.

Sua integração com AWS SQS, Kafka, RabbitMQ e diversas outras fontes de eventos facilita bastante a implementação de arquiteturas orientadas a eventos.

Se você trabalha com microsserviços, processamento assíncrono ou consumidores de filas, vale muito a pena conhecer essa tecnologia.

Minha recomendação para quem está começando: primeiro entenda o funcionamento do HPA, depois instale o KEDA em um cluster de testes e implemente um cenário real com uma fila SQS ou RabbitMQ. Essa experiência ajuda a compreender como os componentes trabalham juntos.

12. Referências oficiais para aprofundamento

• Documentação oficial do KEDA
• Conceitos e arquitetura do KEDA
• Instalação do KEDA
• Scaler AWS SQS
• Autenticação e TriggerAuthentication
• Documentação oficial do HPA

Códigos e configurações deste artigo são exemplos didáticos. Antes de utilizá-los em produção, valide a versão do KEDA, as permissões IAM e os parâmetros da sua aplicação.