ETOOBUSY 🚀 minimal blogging for the impatient
As you might have probably guessed by now, I’m looking a lot into kubernetes lately, collecting definitions and interesting pieces of data as I read around.
Being about the third time I stumble upon operators, I thought it best to write something for when my future self will be looking around this piece of information time and again.
What is an Operator?
I think the following definition from What is an Operator is quite clear and to the point:
The goal of an Operator is to put operational knowledge into software. Previously this knowledge only resided in the minds of administrators, various combinations of shell scripts or automation software like Ansible. It was outside of your Kubernetes cluster and hard to integrate. With Operators, CoreOS changed that.
Operators implement and automate common Day-1 (installation, configuration, etc) and Day-2 (re-configuration, update, backup, failover, restore, etc.) activities in a piece of software running inside your Kubernetes cluster, by integrating natively with Kubernetes concepts and APIs. We call this a Kubernetes-native application. With Operators you can stop treating an application as a collection of primitives like Pods, Deployments, Services or ConfigMaps, but instead as a single object that only exposes the knobs that make sense for the application.
As indicated in the explanation above, it was all started by CoreOS in their blog post Introducing Operators: Putting Operational Knowledge into Software:
An Operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts but includes domain or application-specific knowledge to automate common tasks.
How is it realized?
Custom resources are extensions of the Kubernetes API, which usually address two different halves, i.e. defining how the API is extended (in terms of endpoints) and what actions should be done to ensure that the new resources follow the same principles of declaration-based behavior as all built-in resources.
So… packing applications? Again?
Q: How is this different than Helm?
A: Helm is a tool for packaging multiple Kubernetes resources into a single package. The concept of packaging up multiple applications together and using Operators that actively manage applications are complementary. For example, traefik is a load balancer that can use etcd as its backend database. You could create a Helm Chart that deploys a traefik Deployment and etcd cluster instance together. The etcd cluster would then be deployed and managed by the etcd Operator.
As I read it, they can be considered somehow complementary, to the point that - probably - Helm is a bit more flexible to play around, while operators fit better when technologies are more stable. This is totally my opinion!
We’re just scratched the surface, but you should now have a clearer idea of what operators are and what purpose they serve. Please comment!