A database in Kubernetes doesn't need only a Pod and a PVC. It needs failover, backup, restore, upgrade, replica, monitoring, and disaster recovery. Packaging all of this in YAML is unsustainable.

An operator is the answer: a controller that encodes the operational knowledge of an application.

Course seal: tested on Kubernetes 1.35 with CloudNativePG, ECK, MinIO, RabbitMQ, and Redis.

The core idea

An operator extends the Kubernetes API with a CRD (CustomResourceDefinition) and a controller that reconciles the desired state.

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

Example: instead of creating Deployment + Service + PVC + failover scripts, you create a CloudNativePG Cluster and the operator does the rest.

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

Anatomy of an operator

Component	Role
CRD	defines the new type and its fields
CR	instance of the type (your request)
Controller	reconciliation loop
RBAC	controller permissions
Webhooks	validation/mutation
Finalizers	cleanup before deletion

The controller runs a loop: it observes the current state, compares it with the desired state, and acts. If a pod dies, it recreates it. If the primary fails, it promotes the replica. If the backup fails, it records status.

Operators we use

Operator	Resource	What it manages
CloudNativePG	Cluster	PostgreSQL HA, backup, failover
ECK	Elasticsearch	Elasticsearch cluster
MinIO Operator	Tenant	object storage
RabbitMQ Cluster Operator	RabbitmqCluster	quorum queues
Spotahome Redis Operator	RedisFailover	Redis with Sentinel

When to use it (and when not)

Use an operator when:

• The application has state and a complex lifecycle (database, queue, storage).
• You need HA, backup, and upgrade safely.
• The community actively maintains the operator.

Avoid when:

• A Deployment + Service suffices (stateless).
• The operator is abandoned or incompatible with your version.
• You don't understand what it does: an operator is not a black box.

An operator is not magic

It does not replace:

• Tested backup (restore is yours).
• Planned capacity.
• Incident runbook.
• Understanding of the database.

It automates what you already know how to do. If you don't know what a failover is, the operator will just fail faster.

Operator + GitOps

The mature way: operator installed via Helm/ArgoCD and CRs versioned in Git.

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

Changes go through PR, review, and sync. No kubectl edit in production.

Lab

1. List the CRDs:

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

2. See the running operators:

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

3. Inspect a CR and its 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 the status: ready instances, primary, conditions.

5. (Lab) Delete a replica and watch the operator recreate it:

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

Common errors

Symptom	Cause
CR Pending	operator not installed or lacking permission
Operator in CrashLoopBackOff	incompatible version or broken webhook
CR accepted but nothing happens	controller is not running
no matches for kind	CRD not installed
Stuck finalizer	external resource not removed
Upgrade broke	CRD/version incompatible with the operator

Checklist

• [ ] I know which operators run in the cluster.
• [ ] I know which CRD each one adds.
• [ ] CRs are in Git, not hand-edited.
• [ ] Operator has a planned upgrade.
• [ ] Backup/restore tested independently of the operator.
• [ ] I understand the CR status/conditions.
• [ ] I have a runbook for the operator being down.

Glossary

• CRD: definition of a new resource type.
• CR: instance of a CRD.
• controller: loop that reconciles state.
• reconciliation: desired vs. actual comparison.
• finalizer: cleanup hook before deletion.
• webhook: validation/mutation in the API.

Next

Now let's go to the most important operator in our stack: PostgreSQL with CloudNativePG — HA, failover, backup, and restore in practice.

Next: Kubernetes Course 15 — Postgres with CloudNativePG: HA, failover, and backup