Kubernetes Operators — A (Very) Brief Overview

People new to the concept of Kubernetes Operators may be confused regarding what exactly they do. An operator is not a client-side installer, yet an operator is not something like Tiller that can install arbitrary applications. Each operator is explicitly written to install and maintain an application (called the “operand”) which consists of a specific set of Kubernetes resources. For example, the (fictitious) “Fabulous Database” operator is responsible for installing and maintaining its operand (which is simply a “Fabulous Database” application that consists of a Deployment, a Config Map, and other resources). It is important to note that one operator can simultaneously manage multiple instances of operands (so one “Fabulous Database” operator could manage multiple “Fabulous Database” applications).

An operator will know what it needs to do by examining a custom resource of a specific kind declared via a CRD that ships with the operator (henceforth, this article will call this custom resource a “CR”). A user tells the operator to install the operand by creating a CR in a namespace that is watched by the operator. A user tells the operator to uninstall the operand by deleting that CR. A user tells the operator to modify an installed operand by modifying the CR.

Rather than regurgitate the operator docs, I wanted to illustrate how things generally work by a simple animation. This article does not talk about Operator Lifecycle Manager (OLM) — OLM is the tool that can be used to install and manage operators themselves. This article also does not cover all the nuances of specific advanced features (like operator dependencies on other operators, support for multiple CRDs, etc). This is just a quick summary to give people who are completely unfamiliar with operators a feel for what the basic workflow is when using operators in your cluster. Just be aware that things can work slightly differently depending on how the operator is configured and implemented.

Here’s an animated workflow described below (slides are found here):

We first start with a “clean” cluster and a cluster-admin (slide 1). The cluster-admin is responsible for installing the operator in its own namespace (2).

The cluster-admin then is responsible for giving permissions for “operand-owners” to be able to create, modify, and delete CRs (3).

An operand-owner will be able to create their own namespace where they want the operand to be installed (4). Within this namespace, the operand-owner will create a CR (5). Let’s assume the operator is watching this namespace for the existence of CRs (and here is where I can get into the weeds and talk about operator Install Modes such as “SingleNamespace” and “AllNamespaces”, but I won’t. Suffice it to say, the operator can watch one, some, or all namespaces for CRs — for this article, I will assume the operator is watching all namespaces for CRs).

Once the operator detects that a CR is created (6), it will immediately deploy an operand (7). If the operand-owner modifies the CR (8), the operator will detect this change (9) and immediately reconfigure the deployed operand’s resources in order to match the configuration found in the CR (10). If the operand-owner deletes the CR (11), the operator will detect the CR’s removal (12) and immediately undeploy the operand’s resources (13).

Note the operand-owner is not responsible for managing any of the operand’s resources! The operand-owner is only responsible for managing the CR. It is the operator’s job to manage all the different parts of the operand (which includes things like Deployments, Config Maps, Service Accounts, Secrets, Roles, etc.).

Finally, we see that there can be multiple operand-owners each in charge of their own CR. One operator can therefore install multiple operand instances. In the example animation above, we see two operand-owners — Bob and Mary (15). Each have their own namespace (16) and their own CR (17–20). The one operator can independently install and maintain Bob and Mary’s operands (21–22). If Bob changes his CR, the operator will change Bob’s operand resources to reflect those changes, but the operator will not alter anything within Mary’s operand. If Bob decides to delete his CR, the operator will uninstall Bob’s operand, while leaving Mary’s operand unchanged (23–24).

There is a lot I did not talk about or cover in this article, as I wanted to keep this short for a quick read aimed at those people unfamiliar with operators. Hopefully, you at least came to a rudimentary understanding of what operators are and how they are generally used.