Kubernetes Operators
This article gives a short overview of Kubernetes Operators. For those who are not familiar with Kubernetes (K8s), it is an open-source platform for managing containerized workloads and services. Please check out all the learning resources available on the K8s website and I also recommend you try out simple K8s tutorials.
Before getting into the details of Operators, let’s talk a bit about what makes an application stateless or stateful?
A stateless application is one that neither reads nor stores information about its state from one time that it is run to the next. Examples are web servers such as Apache, Nginx, and Tomcat. On the other hand, a stateful application can remember at least some things about its state each time that it runs and thus require some persistent storage to keep a track of this state.
What are Operators?
In simple terms, Kubernetes Operator is a process that communicates with the K8s master API and watches for events. When a relevant event occurs, the operator reacts and performs a specific action. It was first introduced by CoreOS in November 2016.
K8s runs and manages your containerized applications using a control-loop which continuously checks the cluster for the desired state of your application. K8s automates most of the deployment, rollback and failover strategies for stateless applications. Lifecycle management of a stateful application can get very challenging. It requires application-specific knowledge to monitor, scale, upgrade and reconfigure the application resources. The ‘Operator’ concept brings in domain-specific knowledge to package, deploy and manage applications.
In formal definition terms, 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.
An example Operator
Some of the things that you can use an operator to automate include:
- deploying an application on demand
- taking and restoring backups of that application’s state
- handling upgrades of the application code alongside related changes such as database schemas or extra configuration settings
- publishing a Service to applications that don’t support Kubernetes APIs to discover them
- simulating failure in all or part of your cluster to test its resilience
- choosing a leader for a distributed application without an internal member election process
What do Operators consist of?
A Kubernetes Operator consists of Kubernetes Custom Resource Definition (CDR) and Kubernetes Custom Controller(s). CRDs only expose those objects that make sense for the application.
An Operator watches for these custom resource types and is notified about their presence or modification. When the Operator receives this notification it will start running a loop to ensure that all the required connections for the application service represented by these objects are actually available and configured in the way the user expressed in the object’s specification.
You can write your Operators in Go, describe them using Ansible, create them based on existing Helm Charts or use Softwares like KUDO (Kubernetes Universal Declarative Operator).
For more details, read the CoreOS’ original article that introduced Operators.
How are Operators different than Helm?
Helm offers a way to package multiple K8s resources and their manifest files into a single package — ‘Chart’.
Helm defines a structure and a convention for a software package identified by different layers of ‘YAML templates’ and a separate layer called ‘Values’ that lets you change the templates. This allows the separation of generic configuration and deployment-specific values. This whole package is called as ‘Helm Charts’. Helm takes templatized YAML files, values file and merges them before deploying the merged YAML to the k8s cluster.
If you were to deploy an application using Helm Chart (without any Operator), the K8s control plane shall take the Helm Charts and deploy a StatefulSet, a Persistent Volume, a Secret, a Service, Pods, etc. Helm is not aware of (and cannot handle) how individual K8s objects interact with each other to form a functioning version of your application.
Both Helm and Kubernetes Operators are complimentary to deploying and managing stateful/complex workloads on Kubernetes. Helm’s primary focus is on the day-1 operation of deploying Kubernetes artifacts in a cluster. The ‘domain’ that it understands is that of Kubernetes YAMLs that are composed of available Kubernetes Resources / APIs. Operators, on the other hand, understand the application-specific logic and are primarily focused on addressing day-2 management tasks of stateful/complex workloads on Kubernetes.
