What is an operator in Kubernetes? In which cases can it be useful to create one, and what should be done to develop one?
These and other questions were answered by Christian De Simone and Simone Recupero with their talk titled “Let’s develop a NET smooth operator” presented on March 22, 2024, in Rome at the “.NET Conference 2024“.
Enjoy the reading.
The case study: building a platform for website deployment
To explain the operators and benefits of this type of solution, Christian and Simone used the example of creating a platform that enables website deployment. At first glance, this doesn’t seem like a complex application, but let’s start adding some requirements:
- Each website must be independent, and any issues within one should not affect the functioning of the others;
- All websites must be scalable (for example, a site experiencing a sudden additional load must continue to function) and fast;
- The creation process must be fully dynamic.
What options do we have?
Let’s forget about Kubernetes and rely on a professional, such as a website administrator, who would do all the work for us. This option is not recommended because it is not dynamic and is not very “automated.”
We can use scripts that contain the kubectl command (the main command to run commands to a Kubernetes cluster) or turn to Helm, a tool for managing Kubernetes resources. These solutions are certainly quick to implement, but at the same time, they are not very secure because they would require exposing the Kubernetes cluster’s APIs. Not only that, but these solutions are also not resilient, not easy to modify, and would require manual monitoring, which is not only boring but also tedious.
What if we exposed the Control Plane APIs? (In a Kubernetes cluster, the Control Plane is the base resource that allows modification of the cluster. These are APIs, which were used by Christian and Simone in the demo shown during the session). A safer solution than the previous one, but not easy to implement. The monitoring phase would also be complex.
We could use the Operator pattern. This would be a completely secure path since it would not require exposing the Kubernetes APIs, and the entire application would run on the cluster being worked on. It is also a simple pattern to use that, among other features, manages many complexities “out of the box.”
Let’s see what the Operator pattern means and how it works.
Operators in Kubernetes
What they are
Operators in Kubernetes are effectively extensions of Kubernetes itself. Kubernetes provides this pattern and suggests its application.
The same Prometheus, a widely used application for event monitoring and therefore logging the pods present in the cluster, is an operator.
How it works
Kubernetes is a framework with an architecture that, among other features, works with declarative states. In short, for each application resource, the expected state is declared, and the Operator, which is essentially a piece of software, performs three actions:
- observes the state of the resource;
- generates a report, which essentially contains information about the difference between the current state (what is present) and the desired state. The verification happens continuously (in technical terms, reconcile loop);
- takes action, meaning that whenever differences between the states are noticed, the Operator applies these differences to the cluster, and consequently, the resources are active and functioning.
The desired state, translated into technical terms, is a Custom Resource Definition, nothing different from the concept of an interface that every programmer already knows. A Custom Resource Definition in Kubernetes defines what a resource should look like, and it is the declarative state that is controlled by an Operator.
A Custom resource is the actual implementation of a Custom Resource Definition, the actual state we want to have.
How are they structured?
Each Operator is made up of two main components:
- watcher: waits and observes events (a pod stopping, a new resource being created, etc.);
- controller: for each event that occurs, it looks for the differences between the two states and applies them to the affected resources. Examples of events: pod deletion, modification of a Custom Resource, etc.
A Practical Example: An Application for Creating Websites
Referring back to the case study at the beginning of their session, Simone and Christian conducted a demo of an application that uses an Operator for creating a website with just a few simple steps.
Below are the two projects, both available online in Christian’s GitHub profile:
- Smooth Operator (https://github.com/TheSimon9/smooth-operator): An Operator, developed in .NET v8, using the KubeOps library, which is part of the official libraries offered by Kubernetes and developed by the community. KubeOps is a true SDK that simplifies the creation of an Operator; thanks to a series of specific commands, it is possible to create all the necessary files (Dockerfile, manifest, etc.) for releasing an Operator.
- Smooth Operator Dashboard (https://github.com/TheSimon9/smooth-operator-dashboard): A simple frontend consisting of a form where the user, after entering the name, address, and message of their website, can create and compile it directly into a Kubernetes cluster.
Filling out the form triggers the publication of the resource (Site in this specific case) in a cluster. The Operator, upon noticing the creation of a Custom Resource, generates the pod.
Christian and Simone, through the Lens IDE, showed the list of pods related to the sites created and released in the Kubernetes cluster, demonstrating how the Operator behaves when a resource is deleted and the corresponding pod is removed.
For any further questions, feel free to contact Christian and Simone.