Las colas y la caché parecen simples hasta el día en que el clúster pierde quórum, la cola deja de aceptar mensajes o Redis comienza a desalojar claves. Este capítulo trata sobre operar esos dos servicios con HA de verdad.

Sello del curso: probado en Kubernetes 1.35 con RabbitMQ Cluster Operator y Spotahome Redis Operator.

RabbitMQ: cola con quórum

El RabbitMQ moderno usa quorum queues (Raft). Sustituyen a las colas clásicas espejadas y exigen mayoría para funcionar.

Un clúster de 3 nodos tolera 1 fallo. Con 2 nodos, no tolera ninguno.

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

El operador crea StatefulSet, Services, secrets y configuración. Servicios típicos:

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

Quórum, PDB y anti-affinity

• 3 réplicas en nodos diferentes (anti-affinity).
• PDB minAvailable: 2 para no perder quórum en drain.
• Recursos definidos: RabbitMQ sufre con memoria baja y disco lleno.

RabbitMQ tiene dos alarmas clásicas:

• Memory alarm: bloquea a los publishers cuando supera el límite.
• Disk alarm: bloquea a los publishers cuando el disco libre cae por debajo del límite.

Supervise rabbitmq_queue_messages, rabbitmq_queue_consumers, memoria y disco.

Colas, DLQ y políticas

• Configure un dead-letter exchange para los mensajes que fallan.
• Defina TTL y max-length para evitar una cola infinita.
• Use policies para aplicar configuraciones a las colas por defecto.
• Cree vhosts y usuarios separados por aplicación.

Credenciales: el operador genera un secret (rabbitmq-default-user). No use el usuario default en la aplicación; cree un usuario con permisos mínimos.

Redis: caché y estado

Redis se usa como caché, sesión, rate limit y lock. Hay dos decisiones:

1. ¿Caché pura? Puede perder datos; configure maxmemory y maxmemory-policy (p. ej.: allkeys-lru).
2. ¿Estado? Necesita persistencia (AOF/RDB) y HA con centinela.

El Spotahome Redis Operator crea RedisFailover con réplicas y centinelas:

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

Servicios:

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

La aplicación habla con el centinela, que descubre el master. Si el master cae, el centinela promueve una réplica.

Redis: memoria y eviction

Sin maxmemory, Redis consume hasta el límite del nodo y es eliminado por el OOM killer.

maxmemory 400mb
maxmemory-policy allkeys-lru

Para caché, allkeys-lru es razonable. Para cola/lock, la eviction puede ser catastrófica — no use la misma instancia para caché y estado.

Supervise:

• redis_memory_used_bytes
• redis_evicted_keys_total
• redis_connected_clients
• latencia y comandos lentos

Laboratorio

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

Acceda al management mediante port-forward y vea colas/consumidores.

2. Redis:

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

3. Elimine un pod de cada uno y observe la recuperación:

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

4. Pruebe drain con PDB: vea cómo el drain respeta minAvailable.

Errores comunes

Síntoma	Causa
RabbitMQ no acepta publish	memory/disk alarm
Cola no disponible	pérdida de quórum (2 de 3)
Mensajes acumulándose	consumidor parado o lento
Redis OOMKilled	sin maxmemory/límite
Eviction inesperada	política allkeys-* en dato crítico
Centinela no encuentra master	red/DNS o quórum de centinela
Drain bloqueado	PDB sin réplicas suficientes

Checklist

• [ ] RabbitMQ con 3 réplicas y quorum queues.
• [ ] PDB y anti-affinity configurados.
• [ ] Alarmas de memoria/disco supervisadas.
• [ ] DLQ y TTL definidos.
• [ ] Redis con maxmemory y política adecuada.
• [ ] Centinelas con 3 réplicas.
• [ ] Credenciales por aplicación, sin default.
• [ ] Runbook para pérdida de quórum.

Glosario

• quorum queue: cola Raft de RabbitMQ.
• DLQ: dead-letter queue.
• centinela: servicio de descubrimiento/failover de Redis.
• eviction: eliminación de claves por política de memoria.
• vhost: aislamiento lógico en RabbitMQ.
• PDB: presupuesto de interrupciones.

Próximo

Ahora vamos al buscador: Elasticsearch con ECK, shards, salud del clúster y snapshots.

Próximo: Curso Kubernetes 18 — Elasticsearch/ECK en la práctica