The k8s Operator Pattern

Preface

The kubernetes operator has been playing a vital role in kubernetes ecosystem, it wraps a user designed logic in a daemon and exposed configurable and readable fields for operator users. It's a strong boost of Infrastructure as Data (IaD).

Sometimes people compare IaD with IaC (Infrastructure as Code). The key difference between them is IaC involves code logic eg, conditional statement, for loop etc.. It's not that straightforward as IaD. With IaD you simply see structured data represented as structured language such as Yaml or Json etc. They are much more readable for non-engineering colleagues.

With the advent of AI era, the human machine interaction will be more and more simpler. And the below is the complexity pyramid:

     Natural Language (AI tools)                                
               /              \  
   Configuration as Data (IaD tools)
          /                         \   
Code(Java, Python, IaC tools eg. terraform )          

What is an k8s Operator

First let's address the question is what a k8s operator is. Let's use the typical black method to decouple it:

• Input : the input is k8s Custom Resource(CR) data, restricted by k8s Custom Resource Definition (CRD)
• action : the operator daemon runs repetitively according to reconcile loop and fetches the CR data and delivers output
• output : the output could be producing a new type of object in or within kubernetes cluster. The status field of the k8s object hosts the execution and object states.

To help with understanding the concept, you could think of it as a cronjob running repetitively to accomplish a task. And the task could be data format conversion or making an action. However, a cronjob is more free style comparing to a k8s operator.

The default Operator: kubernetes Deployment

The kubernetes controller Deployment can be seen as a default operator offered by kubernetes. The kubernetes reconcile loop would inspect deployment status continuously, for any process failure resulted in Pod failure, kubernetes would restart a container automatically. Comparing to traditional VM machine deployment, this is a huge improvement, cause during that time we have to compose a startup service file to make it auto restart upon failure. Now that with kubernetes, the operator can deal with failure with a strategy and thereby save human labor work.

In short the Deployment operator does the following things:

• respect kubernetes reconcile loop
• restart container on container process failure
• cease rolling update on pod failure

k8s Operator Example: Argocd

Now let's take a look at a more advanced operator, argocd operator. The Argocd (https://argoproj.github.io/cd/) is known as a Gitops tool deploying kubernetes manifests to target clusters. Essentially it includes an operator pulling application manifest and deploying the Gitops source to target kubernetes clusters. Well, you may say we could also use a Helm command line to deploy a kubernetes application, and raise the question how does Argocd differ from the helm cli .

That is indeed a very good question, Argocd also comes with Helm as a configuration management plugin, and therefore you can take Argocd as a operator version for helm cli. It covers the following aspects that helm cli doesn't have:

• State display with the Argocd web UI, hence avoid remembering helm cli syntax
• Change detection on the github source and auto sync the change to target cluster

Hopefully the difference is clear enough as of now, the operator is like a robot who can continuously check the status of a system and react upon it , whereas a command line is simply a stateless tool follows hit-and-go behavior. And the command line tool only has control of the target at a particular time point. After leaving the command, if no changes on the same we could simply assume the system status is the same as we issue the command.

k8s Operator Example: Crossplane

Crossplane (https://www.crossplane.io/) is another good example of k8s operator. It is an IaD tool enables users defining cloud infrastructures with Yamls, specifically a Cloud resource is represented by a k8s Custom Resources. We can simply understand it as a daemonized terraform using the reconcile loop to apply CRs against the Cloud provider. With Crossplane you don't see complicated HCL language, you could just define your infrastructure with Yaml then Crossplane providers eg. AWS , Azure and GCP providers can translate the user input to Terraform code and provision the infrastructure.

k8s Operator Example: Cert Manager

I believe system engineers have experienced the pain of TLS certificate renewal. The cert manager project successfully removed such pain. By using Cert Manager , a TLS certificate is translated to a kubernetes Custom Resource. And users can simply query certificate properties and status via kubectl commands. Also, the Cert Manager checks the TLS certificate validity periodically and renews it automatically. The manual certificate maintenance work has been significantly reduced. One thing to note is the cert manager project has been graduated from CNCF, see https://www.cncf.io/projects/cert-manager/, which means it has gained community popularity and reliability.

Conclusion

This post mainly focuses on what the operator is and the key difference with a command line. We could use the points below to sum it up:

• cli: a time point action, no control after the command
• operator: a time line influence, a chain of actions(Pipeline) and state control

With more and more resources are using the kubernetes operator, the everything-in-kubernetes pattern is getting more popular. The complex logic is dealt with by the operator pod repetitively and readable Yamls or Custom Resources are exposed to human users. If you need a worker to do repetitive hard work , then think about k8s operators.