Kubernetes has become the de facto container orchestrator since it's initial release in 2014. It is a great tool for managing diverse workloads in clusters of machines, possibly spanning multiple availability zones. As the usage grows, new requirements for how to deploy and operate specialized software emerges. The Operator pattern is one of the more prominent responses to these new requirements.
The Operator pattern is best described in the official Kubernetes documentation:
The Operator pattern aims to capture the key aim of a human operator who is managing a service or set of services. Human operators who look after specific applications and services have deep knowledge of how the system ought to behave, how to deploy it, and how to react if there are problems.
People who run workloads on Kubernetes often like to use automation to take care of repeatable tasks. The Operator pattern captures how you can write code to automate a task beyond what Kubernetes itself provides.
TL;DR Operators automate operation of applications and services with human know-how.
How does an Operator work?
An Operator consists at a minimum of one Custom Resource Definition (CRD) and a Controller. The CRD describes the various configuration options for this kind of resource. Given a custom resource for a PostgresDatabase, one might find options for specifying custom StorageClasses, resource allocation, backup schedule/destinations, authentication methods, etc.
Given an instance (CR) of PostgresDatabase, it's now the job of the controller to ensure that the desired state is reconciled with the cluster. In this example one can assume that the controller will create a StatefulSet for running the database itself, along with needed configuration in a ConfigMap, certificates for mutual TLS in a Secret. Backup can be done by either mounting and writing to a volume defined in the CR or injecting a sidecar for sending backups to another location.
Patching, reboots and failovers can be specified in the CR and taken care of by the controller, using methods recommended by experienced DBA's. The fact that complex operational knowledge can be encoded into the controller is a key enabler for many organizations that would like to run complex software, but not necessarily invest countless hours into learning the nitty-gritty details on how to operate it.
Like any other software there will be bugs and abstractions will leak. There's no silver bullet.
How do I create my own Operator?
As with the rest of the Kubernetes community, multiple solutions exists.
- For a declarative experience, check out KUDU
- If you'd like a more official way to do it, see kubebuilder
- The most popular option seems to be Operator SDK
As with most cloud native software, Go seems to be the lingua franca. There is nothing stopping you from writing an Operator in Java, C#, Python or any other language that can communicate with the Kubernetes APIs.
Examples of known Operators
The community has produced a lot of Operators for about everything one can imagine. These are some popular examples:
- Argo CD – a declarative, GitOps continuous delivery tool for Kubernetes.
- cert-manager – automatically provisions TLS certificates via the ACME protocol. Can be used with certificate issuers such as Let's Encrypt, Buypass and ZeroSSL.
- Prometheus Operator – often used in combination with kube-prometheus for a batteries included monitoring suite
- KubeDB – a real-life implementation of the
PostgresDatabaseexample, plus support for MySQL/MariaDB/MongoDB/Redis/Memcached and more
Header image: RIA Novosti archive, image #305015 / Alexey Danichev / CC-BY-SA 3.0