Operators are software extensions to Kubernetes that make use of third-party resources to manage applications and their components. Operators follow Kubernetes principles, notably the control loop.
The Operator pattern aims to capture the key aim of a human operator who is managing a service or set of services. Human operators who look after specific applications and services have deep knowledge of how the system ought 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 take care of repeatable tasks. The Operator pattern captures how you can write code to automate a task beyond what Kubernetes itself provides.
Kubernetes is designed for automation. Out of the box, you get lots of built-in automation from the core of Kubernetes. You can use Kubernetes to automate deploying and running workloads, and you can automate how Kubernetes 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 code of Kubernetes itself. Operators are clients of the Kubernetes API that act as controllers for a Custom Resource.
Some of the things that you can use an operator to automate include:
What might an Operator look like in more detail? Here’s an example in more detail:
The most common way to deploy an Operator is to add the Custom Resource Definition and its associated Controller to your cluster. The Controller will normally run outside of the control 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.
Once you have an Operator deployed, you’d use it by adding, modifying or deleting the kind of resource that the Operator uses. Following the above example, 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 changes as well as keeping the existing service in good shape.
If there isn’t an Operator in the ecosystem that implements the behavior you want, you can code your own. In What’s next you’ll find a few links to libraries and tools you can use to write your own cloud native Operator.
You also implement an Operator (that is, a Controller) using any language / runtime that can act as a client for the Kubernetes API.
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.