Introduction to Kubernetes operators for sysadmins
Learn about Kubernetes operators and when you should use them—and when you shouldn't.
In May, we presented the Kubernetes Operator Framework at Cloud Native Rejekts '22 in Valencia, Spain. The Operator Framework defines five capability levels, from level 1, a basic install, to level 5, autopilot. The majority of Kubernetes operators settle in the midrange, at level three. The L5 Operator Demo project shows what a level-five operator looks like.
[ Get this complimentary eBook from Red Hat: Managing your Kubernetes clusters for dummies. ]
Before we could even begin to advocate the importance of operator levels and higher capabilities, we hit a roadblock with this pressing question: "Why operators?" Before answering that question or diving into operator levels, our audience needed some foundational knowledge.
This article provides the who, what, when, where, why, and how of operators. We want to simplify operators substantially so that everyone has a high-level understanding of what operators are and why they are so valuable in Kubernetes, open source, and tech communities overall. In a follow-up article, we'll explain how to create an operator.
Who created operators?
Kubernetes operators were first mentioned in a 2016 article titled Introducing operators: Putting operational knowledge into software by Brandon Philips, CTO of CoreOS. His team of site reliability engineers developing software for application domains had been working in the Kubernetes community designing and implementing a concept that would reliably create, configure, and manage complex applications on top of Kubernetes. He named this new class of software "operators."
What are operators?
According to Philips, "An operator is an application-specific controller that extends the Kubernetes API to create, configure, and manage instances of complex applications on behalf of a Kubernetes user."
This isn't an entirely new idea but an extension of existing Kubernetes resources and controller concepts with the addition of application-specific knowledge.
[ Get the Kubernetes glossary. ]
Operators contain three major components: controller, resource, and knowledge.
A controller is a control loop that watches the state of your cluster and moves your current cluster state closer to the desired state. Some examples of controllers that are commonly used in Kubernetes are the Deployment controller, DaemonSet controller, and ReplicaSet controller.
A resouce, or more specifically a custom resource, is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind. Some examples of resources in Kubernetes are pods, secrets, and ConfigMaps.
A custom resource (CR) is a custom operator that users can create to store their own API objects while the API server handles the CR's lifecycle. A CR stores and retrieves structured data. It is an instance of the custom resource definition (CRD), so you must define a CRD before you can create an instance of the CR.
Here is an example of what a CRD looks like:
--- apiversion: apiextensions.k8s.io/v1 kind: CustomResourceDefintion metadata: annotations: controller-gen.kubebuilder.io/version: v0.7.0 creationTimestamp: null name: besties.pets.bestie.com spec: group: pets.bestie.com names: kind: Bestie listkind: Bestielist plural: besties singular: bestie scope: Namespaced versions: - name: v1
Knowledge is domain- or application-specific information that is usually learned by users or administrators rather than developers. Some examples of application-specific knowledge that can be implemented in an operator are installation, scaling, self-healing, backup and restore, updates, clean up, resiliency, and observability.
An L5 operator implements knowledge during its installation stage. The application requires the PostgreSQL database to be seeded before the application pods are instantiated. Therefore, in our operator, we created a job with the required information to seed the database pods before the application pods are created. This ensures that the database exists before the application tries to access it.
[ Learn the basics in the Kubernetes cheat sheet. ]
Operators consist of different capability levels. The Operator Capability Levels infographic below displays the range of knowledge each level is capable of. It also shows which level different operator tooling can achieve. Helm can create operators up to a level-three caliber, while Ansible and Go can create complete level-5 autopilot operators that fully manage applications.
Why are operators valuable?
Operators build an ecosystem of software that can be easy, safe, and reliable to use and operate as a cloud service. They ease the manual workload that Kubernetes users would otherwise have to do and provide an easy way to install and work across applications and software.
They are low touch and remotely managed, with one-click updates. They provide consistency and stability in the world of cloud services and containerization to bring functionality where it's wanted.
The more that people know about operators, the better chance we have to continue enhancing the average capability level of operators in the ecosystem and enable enterprises and developers to create easier, safer, and more reliable cloud-native applications. This leads to even more innovation in the space and more transitions to cloud-native solutions.
The Operator Framework toolkit is open source software. Therefore, operators rely upon the community to create and further develop them into the next generation of application management and automation. The more we work together, the better operators become.
[ Getting started with containers? Check out Deploying containerized applications: A technical overview. ]
When should you use operators?
Of course, as amazing and useful as they are, operators aren't the right answer to all applications. Operators are difficult and can be tedious, depending on your needs. They take time and expert knowledge of your application and can be more work than you bargained for if your application doesn't quite need the help.
So here are some questions to help you decide if your application can benefit from an operator:
- Is your application a stateful application? Operators are most useful when they're helping to manage stateful applications in a Kubernetes setup.
- Does your application contain application-specific tasks that could benefit from managed automation that Kubernetes doesn't already fulfill?
- Could your application benefit from being more scalable, repeatable, and standardized?
If you answer "yes" to these questions, you should consider using operators.
Who is using operators?
Operators are used widely. OperatorHub.io is a community library of existing operators, with listings from Amazon, Dell, Prometheus, PostgreSQL, Grafana, MongoDB, Couchbase, GitLab, Quay, Redis, Red Hat, and others. All of these companies have operators available in OperatorHub.
Our next article will show you how to create your own operator.
[ Want to test your sysadmin skills? Take a skills assessment today. ]
Sometimes the process to delete Kubernetes namespaces gets hung up, and the command never completes. Here's how to troubleshoot terminating namespaces
Using Kubernetes labels effectively requires an understanding of tagging methods, labeling use cases, best practices, and things you definitely want to avoid.
RHACS monitors runtime data on containers to help you uncover potential vulnerabilities during product testing.