Operator pattern

Operators are software extensions to Kubernetes that make use of customresourcesto manage applications and their components. Operators followKubernetes principles, notably the control loop.

Motivation

The Operator pattern aims to capture the key aim of a human operator whois managing a service or set of services. Human operators who look afterspecific applications and services have deep knowledge of how the systemought to behave, how to deploy it, and how to react if there are problems.

People who run workloads on Kubernetes often like to use automation to takecare of repeatable tasks. The Operator pattern captures how you can writecode to automate a task beyond what Kubernetes itself provides.

Operators in Kubernetes

Kubernetes is designed for automation. Out of the box, you get lots ofbuilt-in automation from the core of Kubernetes. You can use Kubernetesto automate deploying and running workloads, and you can automate howKubernetes does that.

Kubernetes’ controllersA control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.concept lets you extend the cluster’s behaviour without modifying the codeof Kubernetes itself.Operators are clients of the Kubernetes API that act as controllers fora Custom Resource.

An example Operator

Some of the things that you can use an operator to automate include:

• deploying an application on demand
• taking and restoring backups of that application’s state
• handling upgrades of the application code alongside related changes suchas database schemas or extra configuration settings
• publishing a Service to applications that don’t support Kubernetes APIs todiscover them
• simulating failure in all or part of your cluster to test its resilience
• choosing a leader for a distributed application without an internalmember election process

What might an Operator look like in more detail? Here’s an example in moredetail:

• A custom resource named SampleDB, that you can configure into the cluster.
• A Deployment that makes sure a Pod is running that contains thecontroller part of the operator.
• A container image of the operator code.
• Controller code that queries the control plane to find out what SampleDBresources are configured.
• The core of the Operator is code to tell the API server how to makereality match the configured resources.
  • If you add a new SampleDB, the operator sets up PersistentVolumeClaimsto provide durable database storage, a StatefulSet to run SampleDB anda Job to handle initial configuration.
  • If you delete it, the Operator takes a snapshot, then makes sure thatthe StatefulSet and Volumes are also removed.
• The operator also manages regular database backups. For each SampleDBresource, the operator determines when to create a Pod that can connectto the database and take backups. These Pods would rely on a ConfigMapand / or a Secret that has database connection details and credentials.
• Because the Operator aims to provide robust automation for the resourceit manages, there would be additional supporting code. For this example,code checks to see if the database is running an old version and, if so,creates Job objects that upgrade it for you.

Deploying Operators

The most common way to deploy an Operator is to add theCustom Resource Definition and its associated Controller to your cluster.The Controller will normally run outside of thecontrol planeThe container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers.,much as you would run any containerized application.For example, you can run the controller in your cluster as a Deployment.

Using an Operator

Once you have an Operator deployed, you’d use it by adding, modifying ordeleting the kind of resource that the Operator uses. Following the aboveexample, you would set up a Deployment for the Operator itself, and then:

kubectl get SampleDB                   # find configured databases
kubectl edit SampleDB/example-database # manually change some settings

…and that’s it! The Operator will take care of applying the changesas well as keeping the existing service in good shape.

Writing your own Operator

If there isn’t an Operator in the ecosystem that implements the behavior youwant, you can code your own. In What’s next you’ll find a fewlinks to libraries and tools you can use to write your own cloud nativeOperator.

You also implement an Operator (that is, a Controller) using any language / runtimethat can act as a client for the Kubernetes API.

What's next

• Learn more about Custom Resources
• Find ready-made operators on OperatorHub.io to suit your use case
• Use existing tools to write your own operator, eg:
  • using KUDO (Kubernetes Universal Declarative Operator)
  • using kubebuilder
  • using Metacontroller along with WebHooks thatyou implement yourself
  • using the Operator Framework
• Publish your operator for other people to use
• Read CoreOS’ original article that introduced the Operator pattern
• Read an article from Google Cloud about best practices for building Operators

Feedback

Was this page helpful?

Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it onStack Overflow.Open an issue in the GitHub repo if you want toreport a problemorsuggest an improvement.