Una base de datos en Kubernetes no solo necesita un Pod y un PVC. Necesita failover, backup, restore, upgrade, réplica, monitoreo y recuperación ante desastres. Empaquetar todo eso en YAML es insostenible.

Operador es la respuesta: un controller que codifica el conocimiento operativo de una aplicación.

Sello del curso: probado en Kubernetes 1.35 con CloudNativePG, ECK, MinIO, RabbitMQ y Redis.

La idea central

Un operador extiende la API de Kubernetes con un CRD (CustomResourceDefinition) y un controller que reconcilia el estado deseado.

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

Ejemplo: en lugar de crear Deployment + Service + PVC + scripts de failover, creas un Cluster de CloudNativePG y el operador hace el resto.

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

Anatomía de un operador

Pieza	Rol
CRD	define el nuevo tipo y sus campos
CR	instancia del tipo (tu pedido)
Controller	loop de reconciliación
RBAC	permisos del controller
Webhooks	validación/mutación
Finalizers	limpieza antes de eliminar

El controller ejecuta un loop: observa el estado actual, lo compara con el deseado y actúa. Si un pod muere, lo recrea. Si el primario falla, promueve la réplica. Si el backup falla, registra el estado.

Operadores que usamos

Operador	Recurso	Qué gestiona
CloudNativePG	Cluster	PostgreSQL HA, backup, failover
ECK	Elasticsearch	clúster Elasticsearch
MinIO Operator	Tenant	almacenamiento de objetos
RabbitMQ Cluster Operator	RabbitmqCluster	colas con quórum
Spotahome Redis Operator	RedisFailover	Redis con sentinel

Cuándo usar (y cuándo no)

Usa un operador cuando:

• La aplicación tiene estado y ciclo de vida complejo (base de datos, cola, storage).
• Necesitas HA, backup y upgrade con seguridad.
• La comunidad mantiene el operador activo.

Evítalo cuando:

• Un Deployment + Service lo resuelve (stateless).
• El operador está abandonado o sin compatibilidad con tu versión.
• No entiendes lo que hace: un operador no es una caja negra.

El operador no es magia

Él no sustituye:

• Backup probado (el restore es tuyo).
• Capacidad planificada.
• Runbook de incidentes.
• Entendimiento de la base de datos.

Él automatiza lo que ya sabes hacer. Si no sabes qué es un failover, el operador solo fallará más rápido.

Operador + GitOps

La forma madura: operador instalado con Helm/ArgoCD y CRs versionados en Git.

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

Los cambios pasan por PR, revisión y sync. Nada de kubectl edit en producción.

Laboratorio

1. Lista los CRDs:

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

2. Ve los operadores ejecutándose:

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

3. Inspecciona un CR y su estado:

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. Observa el estado: instancias listas, primario, condiciones.

5. (Lab) Derriba una réplica y observa cómo el operador la recrea:

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

Errores comunes

Síntoma	Causa
CR Pending	operador no instalado o sin permiso
Operador en CrashLoopBackOff	versión incompatible o webhook roto
CR aceptado pero no pasa nada	controller no está ejecutándose
no matches for kind	CRD no instalado
Finalizer atascado	recurso externo no eliminado
Upgrade se rompió	CRD/versión incompatible con el operador

Checklist

• [ ] Sé qué operadores se ejecutan en el clúster.
• [ ] Sé qué CRD agrega cada uno.
• [ ] Los CR están en Git, no editados a mano.
• [ ] El operador tiene un upgrade planificado.
• [ ] Backup/restore probado independientemente del operador.
• [ ] Entiendo el estado/condiciones del CR.
• [ ] Tengo un runbook para el operador fuera de línea.

Glosario

• CRD: definición de un nuevo tipo de recurso.
• CR: instancia de un CRD.
• controller: loop que reconcilia el estado.
• reconciliación: comparación deseado × real.
• finalizer: gancho de limpieza antes de la eliminación.
• webhook: validación/mutación en la API.

Próximo

Ahora vamos al operador más importante de nuestro stack: PostgreSQL con CloudNativePG — HA, failover, backup y restore en la práctica.

Próximo: Curso Kubernetes 15 — Postgres con CloudNativePG: HA, failover y backup