Getty Images
Kubernetes operator vs. controller: What's the difference?
Kubernetes operators and controllers both manage cluster resources but play distinct roles in the Kubernetes ecosystem. Explore their differences and learn when to use each.
One of Kubernetes' standout features is its ability to automatically implement a desired state. You describe what you want to happen, and the control plane takes care of the rest.
To implement this, Kubernetes relies on controllers and operators. Both methods are responsible for making sure the actual state of resources conforms to the desired state defined in Kubernetes configurations.
However, there are some nuanced differences between controllers and operators. To ensure a successful Kubernetes deployment, it's important to understand to know which option is best suited for your configuration needs.
What is a Kubernetes controller?
Kubernetes controllers are based on control loops, a concept from control systems theory. A control loop is a continuous cycle in which a resource's actual state is automatically compared to the desired state to keep the two states in alignment.
As an example, imagine you're driving a car in cruise control mode, with the desired speed set to 65 mph. A control loop monitors the vehicle's actual speed and brings it as close as possible to the desired speed of 65 mph. Whenever the actual speed diverges from the desired speed, the control loop detects the deviation and attempts to bring the two speeds into alignment.
The idea behind Kubernetes controllers is similar. Like control loops, controllers in Kubernetes check which conditions admins have requested and work to enforce those conditions automatically.
A Kubernetes controller is any entity that monitors resources and determines whether the current state matches the configured state. If it doesn't, the controller then tries to align resources with the desired state.
Built-in vs. custom Kubernetes controllers
Kubernetes offers a set of built-in controllers, which are installed in every Kubernetes environment by default. Built-in controllers are managed by kube-controller-manager, a daemon built into the Kubernetes control plane.
Examples of built-in controllers include the following:
- Deployment. This controller monitors the state of Kubernetes Deployments, the most common approach to deploying a workload in Kubernetes.
- StatefulSet. This controller provides stateful storage for persistent applications.
- CronJob. This controller runs Jobs -- components of a Kubernetes workload that execute specific tasks -- according to a set schedule.
Kubernetes also supports creating and installing custom controllers. With custom controllers, Kubernetes users can extend Kubernetes' functionalities for specific tasks and workflows.
For example, an admin might regularly need to add certain types of labels for pods in their Kubernetes environment. Writing a custom controller lets the admin create custom labels for pods in ways that aren't supported by built-in controller methods like Deployments.
Kubernetes operators vs. controllers
Operators are custom controllers that use an extension of the Kubernetes API to achieve certain goals. In other words, Kubernetes operators are a specific subcategory of controller that uses API extensions, also known as custom resources.
This definition of a Kubernetes operator might make it sound as though operators are basically the same thing as controllers. This is largely true; an operator is just one type of controller in Kubernetes.
However, there are two important differences between operators and other types of controllers:
- Custom resources. Whereas operators use custom resources, other Kubernetes controllers work without relying on custom resources or Kubernetes API extensions.
- Purpose. Most operators focus on a specific domain; they're designed to help run a particular kind of application. This distinguishes them from other controllers, which serve a generic purpose not tied to a specific domain. For example, the Deployment controller manages all Kubernetes Deployments, not just those associated with a specific type of application.
Operator repositories like OperatorHub contain operators dedicated to handling certain applications or platforms -- such as the monitoring tools Prometheus and Falco -- but not the state of generic Kubernetes resources. This is because generic resources like deployments and pods are managed by built-in controllers using Kubernetes' native control plane functionality rather than API extensions.
When to use Helm charts vs. operators
Operators aren't the only way to add domain-specific applications to Kubernetes. You can also use Helm charts, which install applications automatically.
There's a lot of overlap between operators and Helm charts in terms of what they do. But the two work differently under the hood. A Helm chart consists of YAML code that defines how to run an application, whereas an operator relies on Kubernetes API extensions to do its job.
This means that operators are typically the better approach if you need to add lower-level functionality to Kubernetes. If you just want to run a specific app, however, a Helm chart makes more sense.
