Stop 08 · Kubernetes & OrchestrationTopics · 10/12

Kubernetes Operators (Overview)

In short

Kubernetes can restart a crashed pod, but it doesn't know how to fail over a database or take a backup. Operators teach it those expert jobs, written as code that runs inside the cluster.

A pattern for extending Kubernetes with custom controllers that manage complex, stateful applications (like databases) using domain-specific automated logic — an advanced topic worth knowing conceptually.

The mascot, as a building caretaker with a toolbox, checks a diesel generator and a water tank on the roof.

Think of it like this

The experienced building caretaker

A new guard can open the gate. The old caretaker knows when the generator needs diesel, how to switch to the backup water tank and what to do when the lift jams. An Operator is that caretaker for one app: years of know-how, running on its own.

Watch it happen

An operator running a Postgres cluster

You

API server

Operator

DB pods

apply kind: Cluster

1/6You create a custom resource saying 'I want a 3-instance Postgres'. It's just YAML, like a Deployment.

The big ideas

What you need to know

Custom resources

A CRD adds a new object type, like Cluster or Certificate, to the Kubernetes API.

Custom controllers

The operator runs the same watch-and-reconcile loop as built-in controllers, but with app-specific logic.

Ops knowledge as code

Install, upgrade, backup, failover: steps a human expert would do, automated and repeatable.

Choose carefully

An operator gets broad permissions in your cluster. Prefer mature, well-maintained projects and read what they can touch.

See it in code

Walk through the code

yaml

1# A custom resource handled by the CloudNativePG operator2apiVersion: postgresql.cnpg.io/v13kind: Cluster4metadata: { name: shop-db }5spec:6  instances: 37  storage: { size: 5Gi }

1/2Not a built-in type: the operator's CRD taught the API server what a Cluster is.

This only works after installing the operator, which adds the Cluster type. Run kubectl get crds to see every custom type in a cluster.

Save yourself the pain

Common mistakes

Oops

Writing your own operator for a simple stateless app.

Do this instead

A Deployment, Service and HPA already handle that. Operators earn their place for stateful, complex software.

Oops

Installing an operator from a random repo with cluster-wide permissions.

Do this instead

Check its maintainers, release history and the RBAC it asks for. It will act in your cluster around the clock.

Your mission

Spot the operators

~20 min

Quick check

What makes an operator different from a normal Deployment?

Go deeper

1Read a conceptual explanation of what an Operator does versus a plain Deployment.
2Explore a well-known Operator (e.g. for PostgreSQL) at a high level.
3Understand Operators are typically used for complex, stateful workloads, not simple stateless apps.