Como criar um cluster Redis com Sentinel + HAProxy no Kubernetes (sem dor de cabeça)

Resumo rápido: neste guia, você monta Redis altamente disponível no Kubernetes usando StatefulSet + Sentinel + HAProxy, com failover automático e endpoint estável para as aplicações.

Cenário real: o que quebra primeiro

Se você roda Redis em produção, cedo ou tarde vai acontecer:

nó cai;
pod reinicia no pior horário;
aplicação começa a tomar timeout.

A boa notícia: dá para reduzir esse caos com uma arquitetura simples e pragmática:

Redis em StatefulSet (identidade e volume persistente por pod)
Sentinel (detecta falha e promove réplica)
HAProxy (entrega um endpoint estável e aponta para o master ativo)

Ou seja: a app continua falando com o mesmo host/porta, e o “quem é master” vira problema da infra — como deveria ser.

Arquitetura recomendada

3 pods Redis (redis-0, redis-1, redis-2) em StatefulSet
3 pods Sentinel (quorum mínimo saudável)
2 pods HAProxy (evitar single point of failure)
Services internos:
- headless service para Redis (DNS estável por pod)
- service “normal” para HAProxy (endpoint para apps)

Por que StatefulSet e não Deployment?

Kubernetes já responde isso muito bem: StatefulSet foi feito para workloads com estado.

Você ganha:

identidade de rede estável (redis-0.redis...)
storage persistente por pod (PVC por réplica)
ordem previsível de start/stop/rolling update

Para Redis, isso é ouro. Em Deployment “com sorte funciona”; em StatefulSet “funciona por desenho”.

Sentinel: o cérebro do failover

Sentinel faz quatro coisas importantes:

monitora master e réplicas;
notifica eventos;
promove réplica para master quando necessário;
informa aos clientes qual é o master atual.

Boas práticas:

rodar mínimo 3 sentinels;
distribuir em nós diferentes (anti-affinity);
testar failover periodicamente (sim, em ambiente real também).

Observação importante: Sentinel não transforma replicação assíncrona em mágica. Em falhas extremas ainda pode haver janela de perda de escrita.

HAProxy: endpoint único para suas aplicações

Nem todo cliente Redis é sentinel-aware. E mesmo quando é, muitas equipes preferem simplificar.

O HAProxy resolve isso com health check TCP avançado:

PING espera +PONG
INFO replication espera role:master

Assim ele envia tráfego somente para o master ativo.

Exemplo de backend HAProxy:

backend redis-primary
  mode tcp
  option tcp-check
  tcp-check send PING\r\n
  tcp-check expect string +PONG
  tcp-check send info replication\r\n
  tcp-check expect string role:master
  default-server inter 1s fall 3 rise 2 on-marked-down shutdown-sessions

Exemplo de esqueleto Kubernetes

1) Headless Service do Redis

apiVersion: v1
kind: Service
metadata:
  name: redis
spec:
  clusterIP: None
  selector:
    app: redis
  ports:
    - name: redis
      port: 6379

2) StatefulSet do Redis

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: redis:7
          ports:
            - containerPort: 6379
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 10Gi

3) ConfigMap do HAProxy

apiVersion: v1
kind: ConfigMap
metadata:
  name: haproxy-config
data:
  haproxy.cfg: |
    frontend redis-write
      bind *:6379
      mode tcp
      default_backend redis-primary

    backend redis-primary
      mode tcp
      option tcp-check
      tcp-check send PING\r\n
      tcp-check expect string +PONG
      tcp-check send info replication\r\n
      tcp-check expect string role:master
      default-server inter 1s fall 3 rise 2 on-marked-down shutdown-sessions

4) Criar ConfigMap via kubectl

kubectl create configmap haproxy-config \
  --from-file=haproxy.cfg=haproxy.cfg \
  -n default

Checklist de produção

[ ] PVC por pod Redis
[ ] Pod anti-affinity para Redis e Sentinel
[ ] Requests/Limits de CPU/memória definidos
[ ] PDB (PodDisruptionBudget)
[ ] NetworkPolicy limitando acesso às portas 6379/26379
[ ] Auth no Redis (requirepass / masterauth)
[ ] Monitoramento (latência, memória, failover, role)
[ ] Teste de failover com procedimento documentado

Teste de failover

Descubra o master atual.
Derrube o pod master:

kubectl delete pod redis-0

Ajuste o pod conforme o master ativo no momento.

Observe eleição/promoção via Sentinel.
Valide HAProxy apontando para novo master.
Verifique impacto real na aplicação (timeout/retry/erro).

Se isso falhar no teste, falharia às 3h da manhã. Melhor descobrir agora.

Erros comuns que quase todo mundo comete

Rodar tudo no mesmo nó e chamar isso de HA.
Ignorar DNS/headless service no StatefulSet.
Sem autenticação no Redis “porque é rede interna”.
Não testar failover e confiar na fé.
HAProxy único virando ponto único de falha.

Conclusão

Se você quer Redis estável no Kubernetes, esse combo funciona muito bem:

StatefulSet para consistência de identidade e dados;
Sentinel para failover automático;
HAProxy para endpoint simples e estável.

É uma arquitetura prática, robusta e com manutenção relativamente simples. Não é “zero complexidade” — mas é o tipo de complexidade que compra tranquilidade operacional.

Referências

Arys Tech: Setting Up HAProxy with Redis Sentinel for High Availability on Microk8s Kubernetes

https://arystech.com/blog/setting-up-haproxy-with-redis-sentinel-for-high-availability-on-microk8s-kubernetes

Kubernetes Docs: StatefulSets

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Redis Docs: High availability with Redis Sentinel

https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/

HAProxy Blog: Advanced Redis Health Check

https://www.haproxy.com/blog/haproxy-advanced-redis-health-check

Créditos de imagens

ArysTech — post sobre Redis Sentinel + HAProxy em MicroK8s
Karl Stoney — Redis Sentinel behind HAProxy

Com as tags alta disponibilidade, failover, haproxy, kubernetes, microk8s, redis, redis sentinel, statefulset