Curso Kubernetes 14 — Operadores: o que são e por que usar

Um banco de dados no Kubernetes não precisa só de um Pod e um PVC. Precisa de failover, backup, restore, upgrade, réplica, monitoramento e recuperação de desastre. Empacotar tudo isso em YAML é insustentável.

Operador é a resposta: um controller que codifica o conhecimento operacional de uma aplicação.

Selo do curso: testado em Kubernetes 1.35 com CloudNativePG, ECK, MinIO, RabbitMQ e Redis.

A ideia central

Um operador estende a API do Kubernetes com um CRD (CustomResourceDefinition) e um controller que reconcilia o estado desejado.

CRD (novo tipo) → CR (seu pedido) → controller (reconcilia) → recursos reais

Exemplo: em vez de criar Deployment + Service + PVC + scripts de failover, você cria um Cluster do CloudNativePG e o operador faz o resto.

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: portal-postgres
spec:
  instances: 2
  storage:
    size: 10Gi

Anatomia de um operador

Peça	Papel
CRD	define o novo tipo e seus campos
CR	instância do tipo (seu pedido)
Controller	loop de reconciliação
RBAC	permissões do controller
Webhooks	validação/mutação
Finalizers	limpeza antes de deletar

O controller roda um loop: observa o estado atual, compara com o desejado e age. Se um pod morre, ele recria. Se o primário falha, ele promove a réplica. Se o backup falha, ele registra status.

Operadores que usamos

Operador	Recurso	O que gerencia
CloudNativePG	Cluster	PostgreSQL HA, backup, failover
ECK	Elasticsearch	cluster Elasticsearch
MinIO Operator	Tenant	object storage
RabbitMQ Cluster Operator	RabbitmqCluster	filas com quórum
Spotahome Redis Operator	RedisFailover	Redis com sentinel

Quando usar (e quando não)

Use operador quando:

• A aplicação tem estado e ciclo de vida complexo (banco, fila, storage).
• Você precisa de HA, backup e upgrade com segurança.
• A comunidade mantém o operador ativo.

Evite quando:

• Um Deployment + Service resolve (stateless).
• O operador está abandonado ou sem compatibilidade com sua versão.
• Você não entende o que ele faz: operador não é caixa-preta.

Operador não é mágica

Ele não substitui:

• Backup testado (restore é seu).
• Capacidade planejada.
• Runbook de incidente.
• Entendimento do banco.

Ele automatiza o que você já sabe fazer. Se você não sabe o que é um failover, o operador só vai falhar mais rápido.

Operador + GitOps

O jeito maduro: operador instalado por Helm/ArgoCD e CRs versionados no Git.

infra/operators/cloudnative-pg/   # helm/argocd
apps/portal/postgres-cluster.yaml # CR

Mudanças passam por PR, revisão e sync. Nada de kubectl edit em produção.

Laboratório

1. Liste os CRDs:

kubectl get crd | grep -E 'cnpg|elastic|minio|rabbitmq|redis'

2. Veja os operadores rodando:

kubectl get pods -A | grep -E 'cnpg|elastic|minio|rabbitmq|redis'

3. Inspecione um CR e seu status:

kubectl -n portal-cliente get cluster.postgresql.cnpg.io portal-postgres
kubectl -n portal-cliente get cluster.postgresql.cnpg.io portal-postgres -o yaml | less

4. Observe o status: instâncias prontas, primário, condições.

5. (Lab) Derrube uma réplica e veja o operador recriar:

kubectl -n portal-cliente delete pod portal-postgres-2
kubectl -n portal-cliente get pods -w

Erros comuns

Sintoma	Causa
CR Pending	operador não instalado ou sem permissão
Operador em CrashLoopBackOff	versão incompatível ou webhook quebrado
CR aceito mas nada acontece	controller não está rodando
no matches for kind	CRD não instalado
Finalizer preso	recurso externo não removido
Upgrade quebrou	CRD/versão incompatível com o operador

Checklist

• [ ] Sei quais operadores rodam no cluster.
• [ ] Sei qual CRD cada um adiciona.
• [ ] CRs estão no Git, não editados à mão.
• [ ] Operador tem upgrade planejado.
• [ ] Backup/restore testado independente do operador.
• [ ] Entendo o status/condições do CR.
• [ ] Tenho runbook para operador fora do ar.

Glossário

• CRD: definição de um novo tipo de recurso.
• CR: instância de um CRD.
• controller: loop que reconcilia estado.
• reconciliação: comparação desejado × real.
• finalizer: gancho de limpeza antes da exclusão.
• webhook: validação/mutação na API.

Próximo

Agora vamos ao operador mais importante do nosso stack: PostgreSQL com CloudNativePG — HA, failover, backup e restore na prática.

Próximo: Curso Kubernetes 15 — Postgres com CloudNativePG: HA, failover e backup