Okay, check this out: you install a containerized application on your Kubernetes cluster, which manages other applications for you.
That’s what Kubernetes operators are in a nutshell. But let’s start from the beginning.
Reconciliation
Kubernetes, like other orchestrators, is stuck in an eternal loop - the control loop. It checks what the world looks like, compares it to its note on how the world is SUPPOSED to look like, and performs operations to make reality resemble the desired state.
It’s a reconciliation engine, and takes care of distributing and running workloads across the machines of a cluster by default.
Technically speaking, there are many independently functioning Controllers, responsible for single parts of the cluster, doing their own thing and reacting to changes. But let’s pretend we don’t care about those details for now.
The Target State
How does Kubernetes know what the state of the cluster is supposed to look like?
It’s provided with precise instructions. Usually stored in etcd and accessed through the kube-apiserver, there’s a collection of descriptions what elements should be present on the cluster. There are many types - Pods (groups of containers), Services (virtual IPs for service discovery), ReplicaSets to run multiple instances of a pod definition…
All of these are stored as single metadata entries in the database.
You Can Extend Kubernetes
Every entry in the “this is what the target state is supposed to look like” database of Kubernetes is called a Resource. Not to be confused with available CPU or memory on a system. Those are computational resources.
But you’re not limited to the built-in resource types!
You can tell Kubernetes about new types of entries (custom resource*, for example created via CRDs) and create new entries with those made-up types.
Custom Resources
You’re free to make up any kind of resource you want, but nobody knows what to do with them. The beauty of Kubernetes is, that you tell it what you want the reality of your cluster to look like, and it performs the necessary busywork without you having to care too much about the details.
Unfortunately, it wouldn’t know what you mean by your fancy new resource types.
(Custom) Controllers
Kubernetes runs many built-in controllers internally. Some can be plugged in as needed depending on your cluster’s environment. They are the parts that check what the cluster state looks like, check what the desired state is, do magic stuff until the two are the same.
You can write your own controllers! Or just run ones other people have written. Those custom controllers are run just as any other containerized application in your cluster. However, they have special permissions and can react to changes to the desired cluster state. That’s right, they can deal with custom resources!
Operators
Operators are what happens when you combine custom resources and custom controllers.
Custom resource types are defined, custom controller are started on the cluster, waiting for something to do - and all that’s left to do for you as user, is to create the custom resources you need. The custom controllers will get busy as soon as you do, and operate the application in question.
What Is This Good For?
There are many operators in the Kubernetes ecosystem. They make it easy to run and configure applications on your cluster. Here are some fun examples:
The Prometheus Operator makes it easy to run new instances of Prometheus (for monitoring stuff), and to configure scraping rules for applications - without touching those Prometheus installations! Instead, you create new custom resources and the operator gets busy spinning up new Prometheus instances or adjusting existing configurations. It’s super neat!
The Postgres Operator manages PostgreSQL clusters on Kubernetes. Not something I would use myself but it’s a nifty thing folks like to use. Need a new database? Just create a new set of custom resources, and the operator will create your databases.
There are also operators which manage the state of cluster-external resources for you.
There’s much more out there! Some useful (like the Kubeflow Operator), some more on the funny side (yes, people have written operators to order Pizza, apparently Pizza is infrastructure).
In Conclusion
I think the operator pattern is neat!
You define your own metadata via custom resources. Then you deploy code which performs operations on your cluster (or even outside of it) until the desired state of the world is reached.
Operators are popular in the Kubernetes ecosystem, but when you strip away the fancy stuff, it’s just yet another example of reconciliation engines being useful in a very specific context.
If you’re learning Kubernetes or a curious about it - I hope that knowing about Operators and CRDs will spike your interest even more.