A Kubernetes Operator is a method for application deployment that extends the capabilities of Kubernetes to manage more complex, stateful workloads. Examples of these workloads include databases, distributed systems that use quorum mechanisms and applications that cannot easily be reconfigured in a single step. Even with stateless workloads, Operators help shape a consistent definition of an “application” on Kubernetes.Content Continues Below
To accomplish all of that, Kubernetes Operators codify the accumulated best practices and operational procedures into software running on Kubernetes. What was previously managed by scripts and site reliability engineers (SRE) outside of the cluster is now governed by custom Kubernetes extensions running on the cluster with the managed workload. A few Operators capabilities are potentially complex installation and update routines, lifecycle events like backup, restore, failover or failback and metrics-driven scaling.
While most of the development of Kubernetes focuses on stateless, front-end, API-centric applications, Operators allow the rest of the stack to be brought into the environment as well. This simplifies configuration and management as Kubernetes becomes a crucial aspect of portability for IT and engineering departments. Additionally, Operators support higher uptime and lower operational labor with automatic remediation of configuration drift. This can be achieved with Kubernetes’ own extension mechanisms that make this method platform-independent and driven by the Kubernetes community.
How Kubernetes Operators work
Operators connect to the Kubernetes master API and watch for relevant events. They act as customer Kubernetes controllers, introducing their own object types on the cluster that constantly compare the desired state with the actual state. The desired state is declared in YAML and is expressed by the user who is creating Kubernetes objects.
The Operator watches for these Custom Resource Definitions, or events, and starts to run through its loop whenever such objects appear, are updated or are deleted. Operators are running as Kubernetes Pods on the cluster.
Operators are installed by the cluster administrator but are built to aid the end user. The way Operators integrate with Kubernetes allows users to continue to use kubectl tooling and deal with potentially complex software like with any other, more primitive Kubernetes built-in resources.
Kubernetes Operators vs. Helm
So far, the predominant concept of application packaging and management is known as Helm. This open source project focuses on templating of Kubernetes components and bundling them in a package that can be versioned and shipped to the cluster for deployment. Operators represent an evolution of this concept as they take it one step further to include the rest of the application lifecycle that occurs after the initial deployment. As such, Kubernetes Operators complement Helm charts and users of the Operator software development kit (SDK) can build Operators from Helm charts without writing any code.