Curso Kubernetes 17 — RabbitMQ e Redis: quórum, sentinel e PDB

Filas e cache parecem simples até o dia em que o cluster perde quórum, a fila para de aceitar mensagem ou o Redis começa a despejar chaves. Este capítulo é sobre operar esses dois serviços com HA de verdade.

Selo do curso: testado em Kubernetes 1.35 com RabbitMQ Cluster Operator e Spotahome Redis Operator.

RabbitMQ: fila com quórum

O RabbitMQ moderno usa quorum queues (Raft). Elas substituem as filas clássicas espelhadas e exigem maioria para funcionar.

Um cluster de 3 nós tolera 1 falha. Com 2 nós, não tolera nenhuma.

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbitmq
spec:
  replicas: 3
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: "1"
      memory: 1Gi
  persistence:
    storageClassName: portal-nfs
    storage: 5Gi

O operador cria StatefulSet, Services, secrets e configuração. Serviços típicos:

• rabbitmq (AMQP 5672, management 15672, metrics 15692).
• rabbitmq-nodes (headless).

Quórum, PDB e anti-affinity

• 3 réplicas em nós diferentes (anti-affinity).
• PDB minAvailable: 2 para não perder quórum em drain.
• Recursos definidos: o RabbitMQ sofre com memória baixa e disco cheio.

O RabbitMQ tem dois alarmes clássicos:

• Memory alarm: bloqueia publishers quando passa do limite.
• Disk alarm: bloqueia publishers quando o disco livre cai abaixo do limite.

Monitore rabbitmq_queue_messages, rabbitmq_queue_consumers, memória e disco.

Filas, DLQ e políticas

• Configure dead-letter exchange para mensagens que falham.
• Defina TTL e max-length para evitar fila infinita.
• Use policies para aplicar configurações a filas por padrão.
• Crie vhosts e usuários separados por aplicação.

Credenciais: o operador gera um secret (rabbitmq-default-user). Não use o usuário default na aplicação; crie um usuário com permissões mínimas.

Redis: cache e estado

O Redis é usado como cache, sessão, rate limit e lock. Há duas decisões:

1. Cache puro? Pode perder dados; configure maxmemory e maxmemory-policy (ex.: allkeys-lru).
2. Estado? Precisa de persistência (AOF/RDB) e HA com sentinel.

O Spotahome Redis Operator cria RedisFailover com réplicas e sentinelas:

apiVersion: databases.spotahome.com/v1
kind: RedisFailover
metadata:
  name: portal-redis
spec:
  redis:
    replicas: 3
    resources:
      requests:
        cpu: 50m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi
  sentinel:
    replicas: 3
    resources:
      requests:
        cpu: 20m
        memory: 64Mi

Serviços:

• rfr-portal-redis (Redis master/replica).
• rfs-portal-redis (sentinel).

A aplicação fala com o sentinel, que descobre o master. Se o master cai, o sentinel promove uma réplica.

Redis: memória e eviction

Sem maxmemory, o Redis consome até o limite do nó e é morto pelo OOM killer.

maxmemory 400mb
maxmemory-policy allkeys-lru

Para cache, allkeys-lru é razoável. Para fila/lock, eviction pode ser catastrófica — não use a mesma instância para cache e estado.

Monitore:

• redis_memory_used_bytes
• redis_evicted_keys_total
• redis_connected_clients
• latência e comandos lentos

Laboratório

1. RabbitMQ:

kubectl -n portal get rabbitmqcluster
kubectl -n portal get pods -l app.kubernetes.io/name=rabbitmq
kubectl -n portal get pdb rabbitmq-pdb

Acesse o management via port-forward e veja filas/consumidores.

2. Redis:

kubectl -n portal get redisfailover
kubectl -n portal get pods -l app.kubernetes.io/name=portal-redis

3. Derrube um pod de cada e observe a recuperação:

kubectl -n portal delete pod rabbitmq-server-1
kubectl -n portal delete pod rfr-portal-redis-1
kubectl -n portal get pods -w

4. Teste drain com PDB: veja o drain respeitar minAvailable.

Erros comuns

Sintoma	Causa
RabbitMQ não aceita publish	memory/disk alarm
Fila indisponível	perda de quórum (2 de 3)
Mensagens acumulando	consumidor parado ou lento
Redis OOMKilled	sem maxmemory/limite
Eviction inesperada	política allkeys-* em dado crítico
Sentinel não acha master	rede/DNS ou quórum de sentinel
Drain bloqueado	PDB sem réplicas suficientes

Checklist

• [ ] RabbitMQ com 3 réplicas e quorum queues.
• [ ] PDB e anti-affinity configurados.
• [ ] Alarmes de memória/disco monitorados.
• [ ] DLQ e TTL definidos.
• [ ] Redis com maxmemory e política adequada.
• [ ] Sentinel com 3 réplicas.
• [ ] Credenciais por aplicação, sem default.
• [ ] Runbook para perda de quórum.

Glossário

• quorum queue: fila Raft do RabbitMQ.
• DLQ: dead-letter queue.
• sentinel: serviço de descoberta/failover do Redis.
• eviction: remoção de chaves por política de memória.
• vhost: isolamento lógico no RabbitMQ.
• PDB: orçamento de desrupções.

Próximo

Agora vamos ao buscador: Elasticsearch com ECK, shards, saúde do cluster e snapshots.

Próximo: Curso Kubernetes 18 — Elasticsearch/ECK na prática