Operators

Imagine running a database. An expert knows how to create it, how to back it up, how to replace a failed member, and how to upgrade it safely. What if that expert's knowledge could be written as a program, living inside the cluster? That is an operator. Let's see the pattern.

• Expert knowledge as code
• A custom resource plus a controller
• Runs inside the cluster

The operator pattern

An operator is a custom resource, plus a controller that you write. It uses the same control loop you already know. You declare, I want a database with three members, using the custom resource. The operator reads it, and compares it with reality. If a member is missing, it creates it, with the right storage and settings. If a member fails, it repairs it. If you change the version, it upgrades one member at a time. The skills of a database administrator, run all day, without sleeping.

1. You declareDatabase, 3 members
2. Operator observeswhat really exists
3. Operator actscreate, repair, upgrade
4. Repeatforever

Operators you will meet

You will rarely write one yourself, because excellent operators already exist. Cert manager creates and renews certificates. The Prometheus operator runs monitoring. There are operators for Postgres, My S Q L, Kafka, and Redis, that handle backups and failover. And Argo C D, which we meet soon, is also built this way. Check the operator hub before building anything. When you do write one, frameworks like Kubebuilder and the operator S D K give you most of the structure.

When an operator is worth it

Not everything needs an operator. A stateless web app needs only a deployment, and a service. But, software with complex life cycles, like databases and message queues, benefits enormously. Use an operator when the app needs ordered steps, special recovery, or careful upgrades, and when someone has already written one you trust. Do not build your own for a simple need, because every operator is another program to maintain.

Summary