Kubernetes offers limited initial functionality to ensure flexibility and scalability. K8s Operators are software extensions that make use of Kubernetes APIs to extend behavior. What do we need to know about how they work, and what are the concrete benefits?
Kubernetes has an ace up its sleeve that makes it even more useful, powerful, and flexible. That ace is called an Operator. Operators exist because Kubernetes was designed from the beginning for automation, which is built directly into the very heart of the software. In fact, Kubernetes allows users to automate the deployment and execution of workloads, and also the way that Kubernetes does these things.
This is why Operators are so powerful: they enable complex clusters and systems to operate automatically based on a set of patterns and principles. In short, Operators are patterns that extend the behavior of the cluster without changing the Kubernetes code. Its APIs act as custom resource controllers.
To understand the purpose of an Operator, we must first understand what it is. Then, we can understand how Kubernetes works and why Operators are so useful.
If you are reading this article, you are probably already familiar with Kubernetes. Let's review briefly how Operators fit into its logic.
Kubernetes is open source software for container orchestration, that is, for automating the deployment, sizing, and management of workloads on containers. Created by Google in 2014 - inspired by its own workload orchestration system, Borg - Kubernetes was donated to the Cloud Native Computing Foundation. The CNCF, which is part of the Linux Foundation, now maintains and develops it together with other major companies such as Microsoft and Redhat.
Kubernetes follows two basic principles: simplicity and flexibility on the one hand, and the ability to automate as many functions as possible on the other. These are the main strengths that make it capable of scaling and being usable in extremely diverse contexts and applications.
However, these same principles also limit its initial functionality to a restricted set of commands and operations that are exposed through APIs. To do more complex things, this set must be extended and more sophisticated automations must be created, suited to individual applications and their specific domain of action. This is where the Operators come in.
Kubernetes Operators manage application logic and are part of the Kubernetes control plane. As such, they are controllers that execute loops to check the actual state of the cluster and the desired state, acting to reconcile them when the two states are drifting apart. Simplicity and flexibility plus automation not only enable the creation of Operators. These are also the basic principles that form the cornerstones of the Kubernetes architecture.
The Operator concept was introduced in 2016 by the CoreOS Linux (later Container Linux) development team.
The Kubernetes project defines "Operator" in a simple way: "Operators are software extensions that use custom resources to manage applications and their components". In other words, using Operators enables us to view an application as a single object that exposes only the adjustments that make sense for the application, instead of a collection of primitives (such as Pods, Deployments, Services, or ConfigMaps).
In addition, Operators actually allow for automatic implementation of typical Day-1 tasks (installation, configuration, etc.) and Day-2 tasks (reconfiguration, upgrade, backup, failover, recovery, etc.), for a software running within the Kubernetes cluster, integrating natively with Kubernetes concepts and APIs.
This is why they are called "native Kubernetes applications", and this definition can also be viewed in another, more operational way. K8s Operators are controllers for packaging, managing, and deploying applications on Kubernetes. In order to do these things, the Operator uses Custom Resources (CR) that define the desired configuration and state of a specific application through Custom Resource Definitions (CRD).
The Operator's role is to reconcile the actual state of the application with the state desired by the CRD using a control loop in which it can automatically scale, update, or restart the application. Practically speaking, Kubernetes offers basic commands, primitives, that can be used by Operators to define more complex actions.
Ultimately, Operators are actual programs that run in the cluster and interact through Kubernetes APIs to automate more complex functions than those natively handled by Kubernetes itself.
Leggi anche: Kubernetes: what are the key benefits for companies?
If you think this sounds like an automated software for system administration, you're right. We can think of an Operator as an "expert". We show it what we want and with what tools, and then it works tirelessly to achieve that goal.
From this point of view, Operators are declarative rather than imperative tools, because our role is to define the desired objectives and resources while their responsibility is to adjust the system to keep it as close to the desired state as possible.
An almost infinite number of things can be automated through an Operator, however some typical operations are more common than others.
These are just some of the possible applications of K8s Operators. Do Operators have limits? It depends on programmer capabilities and project requirements.
Let's put it this way: compared to Kubernetes, which allows you to manage an application using its API (and kubectl), an Operator is a controller that extends the functionality of the API and manages complex instances of the application for the user. It does this by using Kubernetes' own resources on the one hand and skills specific to that particular application or domain on the other.
In this way, the Operators serve the purpose of automating the entire life cycle of the software they manage, taking over the classic tasks to be done for day 1 and day 2 that, without automation, would have to be performed by one or more human operators.
Operators are very useful because they are application-specific controllers that extend the functionality of the Kubernetes APIs. In other words, the Operators teach Kubernetes new tricks. But what are the concrete benefits they offer? Let's look at a list of the main advantages.
This last advantage should not be underestimated, because creating an Operator from scratch is not exactly easy. Fortunately, there are several alternatives.
Operators are definitely complex to create from scratch. They require programming skills (preferably GO, but they can be implemented in any language as client/server communications) and a thorough knowledge of Kubernetes native controllers and its operating mechanisms (reconciliation loops).
However, there are frameworks that can reduce this complexity, such as:
Fortunately, as we have seen, Operators can be transferred from one environment to another and configured easily. For this reason a true cottage economy was born, which aims to enrich and simplify the deployment, management, and sizing of applications on Kubernetes through Operators.
To date, there are two official applications where you can search for existing Operators easily:
Operators enable us to find solutions to very different problems. Instead of a list of Operators, let's start with some situations to solve and give some examples.
A very efficient end-to-end solution for Kubernetes cluster monitoring is based on the kube-prometheus stack. It is a collection of Kubernetes manifest, Graphana dashboard, and Prometheus rules combined with documentation and scripts that provide user-friendly monitoring by leveraging the Prometheus Operator.
In this case, we can use Kubernetes Cert-manager Operator that allows us to get SSL certificates issued by a list of certification authorities configured in the cluster. This solution lets us request new certificates on the fly from each of the issuers and automatically use them in the service life cycle.
With Istio Operator, we can install, update, and troubleshoot Istio conflicts automatically. This Operator has very few prerequisites (actually only istioctl) and then it allows both installation and validation of all APIs.
When used in both DevOps and SRE scenarios, this Operator makes it possible to automate the mesh management of the microservices used in the Kubernetes cluster from the start: management, orchestration, security, communications, and monitoring. After that, this initial implementation can be refined in a non traumatic way.
Crossplane is a Kubernetes Operator that makes it possible to create and manage cloud resources with Kubernetes declarative syntax by mapping a collection of CRDs, provided by crossplane-providers, with cloud services offered by the specific vendor. It is designed to be used by application teams, who do not need to write any code to do so. It is basically about automating the creation of resources on the public cloud.
This project is part of CNFC, and as its authors explain, "we created Crossplane to help organizations create their own clouds the way cloud providers create theirs: with a control plane."
The Elastic Kubernetes Operator - officially implemented by the Elastic project - enables the automation of Elastic Search and Kibana on Kubernetes with greatly simplified deployment configurations and easy management. The Operator supports both Frozen Indices for larger storage and Kibana Spaces, Canvas, and Elastic Maps, plus the monitoring part of the Kubernetes infrastructure.
As we have said, the Operators we have seen so far are just a few examples. There are plenty of other Operators: from KNative to Cloud Foundry on Kubernetes to Azure Spring Cloud. Of course, there are also Operators for many other of the most popular types of services and applications as well: Grafana, Jaeger, ArgoCD, MongoDB, and RBAC (the Role Based Access Control model).
Even though all these cases are very different, the same principle always applies. The advantage of Operators is to expand the automation possibilities of Kubernetes. The presence of a broad ecosystem of K8s Operators makes it possible to find ready-made solutions for most uses.