Kubernetes Operators are quickly picking up traction in the developer community as a great way of managing complex applications on Kubernetes.

Using the Operator Framework, an Operator provides many benefits to users by wrapping the logic for deploying and operating an application using Kubernetes constructs.

In this lightboarding video, I’ll walk you through two different scenarios of deploying an application with and without a Kubernetes Operator.

Make sure you subscribe to the YouTube channel to be notified about more videos like this when they are published, and leave us a comment if you’ve got any questions on what I covered.

Learn more

Video Transcript

What are Kubernetes Operators?

Hi everyone, my name is Sai Vennam, and I’m with the IBM Cloud team. Today, we want to talk about Operators. 

Now, I’m not actually talking about operations teams but instead the Operator’s Framework, which can be used on Kubernetes or OpenShift. CoreOS actually introduced the Operator Framework back in 2016. CoreOS is now a part of Red Hat and IBM.

Operator Framework is quickly picking up traction as it’s a great way of managing complex Kubernetes applications.

Kubernetes control loop

Now before I jump into this we want to actually introduce what the Kubernetes control loop is because it’s a core part of the Operators Framework.

In this video, we’re going to be talking about things like deployments and pods, so if you’re not familiar with those, be sure to check out the “Kubernetes Explained” video that I’ve done on those topics.


But let’s get started with exactly what the control loop is in Kubernetes. Now, essentially, the way it starts—the control loop is the core part of Kubernetes—it observes the state of what’s in your actual cluster. So that’s the first step, observe.


Next what it’s going to do, Kubernetes is going to double-check that the state in the actual cluster versus the state that you want it to be. So, it’s going to do a diff. 


And finally, it wants to resolve that diff by acting on it. So the last phase of the control loop is act. 

Now the control loop is core to how Kubernetes works and there’s a controller that basically acts on that for every default resource. Kubernetes comes with a number of default resources.

Example of deploying an application without Operators

Let’s see an example of deploying an application without Operators using these default resources. So, as an end user, the first thing you’re going to want to do is write up some YAML, right, the spec for that actual application.

And for our particular example, let’s say that you know we’re doing a deployment, and in this deployment, we’ll have to define some configuration—things like what’s the image, and maybe the replicas, and maybe some other configuration.

So that’s one Kubernetes resource, and essentially, what you would do is take that and deploy it into your Kubernetes cluster, at which point a deployment is made.

Here’s where the control loop kicks in; so Kubernetes observes the state of your cluster—so we’ve got a Kubernetes cluster here—and checks what’s the difference between what you want versus what’s there.

First thing it notices? There are no pods. So it’s gonna act on that difference and it’s gonna create some pods. 

Now let’s say for a fairly complex application, we don’t just have one YAML but we have a second YAML—maybe it’s for the backend—and so that deploys in the second deployment, and that in turn deploys a pod using the controllers in the control loop.

Now it’s a simple example, but say you want to go through here, scale up the application, make some changes, set up some secrets, environment variables—every single time you have to either create new Kubernetes resources or go in here and edit the existing ones. That can start to get fairly difficult.

Example of deploying an application with Operators

Now, let’s see how that’s done in a world where we’re using Operators. Now, the first thing you would actually need to do is install the Operator itself. So, someone in your team has to create the Operator or maybe you can use one of the many that are out there on OperatorHub or the community is building on the Operators that are available.

So, the first thing you need in your Kubernetes cluster is the OLM—which is the Operator Lifecycle Manager—which basically manages the Operators that you have installed.

Next, you deploy your actual Operator into the cluster. 

The Operator is made up of two major components. The first component and Operator is going to be the CRD. The other one is going to be the controller.

Now, the CRD is basically a custom resource definition; so we’ve talked about default resources—things like deployments and pods—but a custom resource is something that you define as a user in Kubernetes or maybe an Operator defines it so that you can create YAML to work against that custom config.

The controller is basically a custom control loop which runs as a pod in your cluster, and runs this control loop against your custom resource definition.

So, let’s say that an Operator is created for our custom application deployment here—so instead of having to write multiple deployments and setting up config maps and secrets for whatever our cluster needs, we instead, as an end user here, we’ll instead actually just deploy one YAML.

Maybe we called this Operator MyApp—it could be a little bit more meaningful here we can call it stateful app, frontend app, whatever we want it to be. And then we could define some config here, or we can use the defaults that are set—kind of have a choice of options here.

Then, we take this Operator and we deploy it directly into the cluster.

At this point, the Operator takes over, and this is actually responsible for running that control loop and figuring out exactly what needs to be running.

So, it’s going to realize that we need a couple of deployments and the pods. 

Now this is a kind of a format or an approach to managing applications that’s inherently easier and scales better than this approach because as an end-user, you really only have to worry about the config that’s been exposed to you, and the Operator itself manages the control loop and the state of the application—how it needs to look.

Custom Operators

Now, there’s great Operators out there already, things like managing etcd or various databases, or even IBM Cloud Services. So all of those Operators currently exist on OperatorHub.

But, say you want to develop your own, maybe a custom Operator for something that is native to your application architecture—kind of like what we sketched out here. Well, there’s a number of ways you can do that, and there’s something called Operator SDK that allows you to start building out Operators yourself.

Now, I’d say the easiest way to get started with an Operator is to use the Helm one. So Helm (as you may already know, there is a video where David Okun goes over exactly how Helm works—be sure to check that one out), but the Helm approach allows you to take a Helm chart and apply that towards an Operator and expose config. So, it allows you to get to a fairly mature level of an Operator—kind of something like this for a chart that’s already there.

Maturity of Operators: Five Levels

Now, the maturity of Operators—what I’ve sketched out down here—falls into five different levels.

Now, Helm actually hits the first two levels of maturity. Let’s talk about what those levels are. 

Level 1: Basic install

The first one it’s basic install. Essentially, the first level is basically going to allow you to do just provisioning of the resources required.

Level 2: Upgrades

Now the second phase goes a little bit further—it’s gonna allow you to do upgrades. So this supports minor and patch-version upgrades to whatever is defined in your Operator.

Now, Helm gets you that far, what about for the next three levels of maturity? For these, you’re going want to use either Go, or you can also use Ansible.

Now, these will allow you to actually get to all five levels of maturity with Operators.

Let’s quickly talk about what those are.

Level 3: Full lifecycle support

At the third level, we’ve got full lifecycle support. So this is storage lifecycle, app lifecycle—it’s also going to allow you to do things like backup and failure recovery. So that’s something that would be kind of configured and developed into the Operator, whomever developed that one.

Level 4: Insights

Fourth, what we’ve got here is insights. This is going to allow you to get deep metrics and analysis, logging—that kind of thing from your actual Operator.

Level 5: Auto-Pilot

And finally, what we have is something called auto-pilot, and just kind of how it sounds this is going to have a lot more functionality built into Operator itself. Basically, it’s going to allow you to do automatic scaling—horizontal and vertically. It’s going to do automatic config tuning. If your Operator-based app gets into a bad state, it’s gonna identify that automatically.

So, these are kind of five levels of maturity that Operators can have. By looking on OperatorHub, you can see the ones that the community has developed and see what level of maturity that they hit. And then, again, by using Operator SDK, you can build your own Operators using either Helm, Go, or Ansible.


More from Cloud

IBM Cloud VMware as a Service introduces multitenant as a new, cost-efficient consumption model

4 min read - Businesses often struggle with ongoing operational needs like monitoring, patching and maintenance of their VMware infrastructure or the added concerns over capacity management. At the same time, cost efficiency and control are very important. Not all workloads have identical needs and different business applications have variable requirements. For example, production applications and regulated workloads may require strong isolation, but development/testing, training environments, disaster recovery sites or other applications may have lower availability requirements or they can be ephemeral in nature,…

IBM accelerates enterprise AI for clients with new capabilities on IBM Z

5 min read - Today, we are excited to unveil a new suite of AI offerings for IBM Z that are designed to help clients improve business outcomes by speeding the implementation of enterprise AI on IBM Z across a wide variety of use cases and industries. We are bringing artificial intelligence (AI) to emerging use cases that our clients (like Swiss insurance provider La Mobilière) have begun exploring, such as enhancing the accuracy of insurance policy recommendations, increasing the accuracy and timeliness of…

IBM NS1 Connect: How IBM is delivering network connectivity with premium DNS offerings

4 min read - For most enterprises, how their users access applications and data is an essential part of doing business, and how they service those application and data responses has a direct correlation to revenue generation.    According to We Are Social’s Digital 2023 Global Overview Report, there are 5.19 billion people around the world using the internet in 2023. There’s an imperative need for businesses to trust their networks to deliver meaningful content to address customer needs.  So how responsive is the…

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…