The case for using operators
Introduction to what Kubernetes Operators are and why you need to use them
Kubernetes Operators have a reputation for being complicated, which might make you wonder why you actually need to use them. In short, they solve specific problems related to cloud-native development that other technology can’t solve as effectively. This article highlights the problems that Kubernetes Operators solve and why to use one.
What are Kubernetes Operators?
First, let’s define what Kubernetes Operators are. These operators are extensions to Kubernetes that use custom resources to manage Kubernetes-native applications and their components. Kubernetes Operators are used to automate software configuration and maintenance activities that are typically performed by human operators.
What problem does a Kubernetes Operator solve?
Building scalable, distributed cloud-native solutions results in many moving parts. While cloud-native development leads to more performant (and upgradeable-by-component) solutions, there are unique challenges related to deploying and maintaining such applications.
For many years, the Kubernetes community focused on solving how to deploy and then upgrade a cloud-native application. A number of solutions exist, and the most popular one is Helm. At their core, solutions such as Helm provide a common method for describing how to configure Kubernetes components for an application. Helm, for instance, simplifies the installation, upgrading, or deletion of applications. However, it is not designed for managing the application instances running in the cluster. Operations outside of the basic scope might be application-specific, requiring specific application knowledge to be carried out reliably and safely. For example, how do you ensure that caches are written through before maintenance operations happen? How might you circulate or synchronize security tokens when they change? Such actions are often referred to as Day 2 operations, where the install activity is considered a Day 1 operation.
Typically, a human operator needs to control these application-specific Day 2 operations, implementing a series of steps to perform an overall task. Enter the Kubernetes Operator.
A Kubernetes Operator provides a standardized structure that incorporates the human operator’s knowledge in an automated way, which minimizes the need for real-time human support. While operators usually do provide Day 1 operations (i.e. install), it is their ability to encode Day 2 operations that sets them apart. People often say that Kubernetes Operators “automate activities for a human operator”. In other words, Kubernetes Operators can minimize or remove the “3:00 AM call” for the site reliability engineer!
Why writing a script might not be the best solution
The first solution that you might try is to script a series of steps that you can externally apply to your cluster. Indeed, you might achieve some, if not all, of the necessary tasks with such an approach. A challenge to this approach is that you must recode many of the cloud-native patterns and approaches that are reused in external applications. Plus, externally applied actions are harder to monitor.
Operators can offer a better option; they incorporate human knowledge inside the cluster with access to all of the internal cloud-native concepts and support that Kubernetes provides. Operators are application-specific extensions to Kubernetes; they give those applications access to concepts and support that is usually added by human operators.
This operator concept was first launched by CoreOS for stateful applications such as databases, caches, and monitoring systems. Kubernetes deals with the deployment of both stateful and stateless distributed applications. However, handling full-fledged scaling, upgrading, and reconfiguration of operations without losing data or availability is a bigger challenge. This requires application domain knowledge that is usually driven by the human operator.
As you go through the learning path, keep the following questions in mind:
- Where is the best place for this application-specific logic to be placed?
- Would access to the internal cloud-native concepts within Kubernetes itself help the implementation?
- How could the progress of the application-specific logic be monitored?
- How could this logic be most easily kept in sync with the code of the actual application itself?
Next step: See an example Day 2 operator in action
Now that you have an idea about the power of Kubernetes Operators, the next part of this learning path shows an example of an operator in action so you can discover the detailed advantages of the operator approach. Specifically, you see an application-specific operation within a Kubernetes application that uses an external database.