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.
3 min read
By Even Holthe
December 11, 2020
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.
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 (
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.
As with the rest of the Kubernetes community, multiple solutions exists.
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.
The community has produced a lot of Operators for about everything one can imagine. These are some popular examples:
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