Skip to main content

Introduction to Kubernetes operators for sysadmins

Learn about Kubernetes operators and when you should use them—and when you shouldn't.
Image
White ship wheel overlooking water and container ships

Image by LivyBo from Pixabay

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.

Image
Image of the three components of an operator.
(Manna Kong, CC BY-SA 4.0)

1. Controller

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.

2. Resource

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

3. Knowledge

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. ]

Operator capability

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.

Image
Image showing the levels of an Operator
(Source: Operator Framework)

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. ]

Check out these related articles on Enable Sysadmin

Image
Label tags hanging by threads
Using Kubernetes labels effectively requires an understanding of tagging methods, labeling use cases, best practices, and things you definitely want to avoid.
Topics:   Kubernetes   Containers  
Author’s photo

Manna Kong

Manna is a Hmong-American woman located in the Midwest. She works as an Associate Software Engineer on the Operator Enablement and Tooling team within the Red Hat Ecosystem Experience Engineering organization. More about me

Author’s photo

Soundharya Pabba

I'm a 23-year-old international professional working as a Software Engineer at RedHat in the Operator Enablement Team. My team works on OpenShift, Kubernetes, and Operators, helping partners build their Kubernetes Operators and conducting various operator development workshops. More about me

Red Hat Summit 2022: On Demand

Get the latest on Ansible, Red Hat Enterprise Linux, OpenShift, and more from our virtual event on demand.

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX

Privacy Statement