The Kubernetes terms "controller" and "operator" refer to two different patterns that transition a cluster into a desired state. Controllers are an established concept whereas Operators have emerged more recently to describe application-specific controllers.

The Control Loop

Kubernetes clusters function on a control loop. You define what the cluster should be doing by writing and applying YAML manifests. Controllers inside the cluster detect the requested changes and take action to adjust the state. This occurs asynchronously, after you've submitted your new manifests.

Controllers are responsible for monitoring the cluster's resources, assessing whether they've diverged from the defined state, and making any necessary adjustments to bring them back into alignment. They are fully automated components which run without intervention.

Several kinds of controller exist within the ecosystem. Some act at the cluster level whereas others manage your workloads. Everyday Kubernetes resources you define in your manifests can be controllers:

        Deployment
    

,

        ReplicaSet
    

, and similar examples meet the definition of a controller. They take charge of nested objects to maintain a user-defined replica count.

What Makes a Controller?

A controller is anything inside your cluster that tracks at least one other Kubernetes resource type. Controllers can be passive or active. An active controller will effect necessary actions itself; passive ones will communicate changes to other components or the cluster API server.

As the role of a controller is intentionally abstract, they have no common functionality beyond their monitoring of specific objects. You could have a controller that automatically deletes Pods with an

        eligible-for-autodelete
    

annotation.

In Kubernetes, controllers are just a pattern for implementing automated control loop functionality. Individual controllers will have unique purposes and traits but they'll always be monitoring your cluster's objects or configuration.

What About Operators?

An operator is a specialized form of controller. Operators implement the controller pattern, meaning they move the cluster towards a defined state, but they possess some extra characteristics too. The term was originally coined by CoreOS but has now been adopted more broadly by Kubernetes too.

Operators are tailored to specific applications. They add Kubernetes API extensions via custom resource definitions, creating new object types that are used by the application they manage.

Several popular community applications now come with their own operators. These make it easier to install, configure, and maintain the managed software in your cluster. There are operators for etcd, Fluentd, Prometheus, and many other critical projects that are commonly launched into clusters.

These workloads can be complex and made from several individual components. They're likely to include application-specific logic that needs to be managed across the installation's lifecycle.

The operator concept provides a way to monitor these applications using the same principles as regular controllers. An operator is simply a specialized controller that uses custom resources to move a specific application into the correct user-defined state.

You typically configure operators by providing config data in a custom resource. The operator uses its knowledge of the application to convert that data into specific actions in the cluster. Those actions will assemble a functioning install of the app that matches the state defined in the config resource.

What Are Operators Used For?

As operators are domain-specific, each one will include different functionality. In general, you can expect an operator to offer some of the following features:

• Automatic monitoring and alerting - Operators usually know when their applications aren't working properly and generate appropriate alerts.
• Automatic version upgrades over time - Operators are often capable of automatically applying cluster changes to install new app updates as they become available. This significantly reduces the maintenance burden for ops teams.
• Installing custom resources - Operators will add the app's custom resources to the Kubernetes API server, preparing the cluster to host the workload.
• Provide auto-scaling - An operator with domain-specific knowledge can recognize when the configured replica count is too low to comfortably serve current traffic and spin up new instances to maintain performance.
• Lifecycle management - Operators ensure new application instances launch into an environment where all prerequisites are already met. They'll also perform any needed clean-up after a replica stops.
• Storage management and backups - Some operators assist the set up of persistent storage. As they understand their application, they may also make backups before applying a potentially destructive action.

Assembling all this functionality from scratch before deploying a new workload would be complicated and challenging to maintain. Operators let you launch complex systems into your cluster using a vendor-approved strategy that's self-managing and Kubernetes-native.

The benefits of operators can be clearly observed in some of the applications which offer them. The GitLab version control software is a complex stack of components but its operator provides fully automated auto-scaling, rolling upgrades and backups, as well as a metric visualization stack using Prometheus and Grafana. It's all ready to use when you add the operator to your cluster.

Another operator is that of MongoDB: it offers a fully-managed way to provision storage, databases, users, and Mongo settings from a single set of specifications you define. The operator then configures your cluster accordingly to support your database workload.

You can write your own operators by creating a controller using one of the Kubernetes client libraries. Operators are developed by using the Kubernetes REST API to query and interact with the cluster and its objects.

Conclusion

Controllers and Operators are Kubernetes terms to describe control plane components that monitor resources and apply actions to modify the cluster's state. Whereas controllers are concerned with Kubernetes-level operations, operators possess domain-specific logic and are tailored to individual applications.

If you use an operator to install an application, it means you're adding a component that will watch that installation, check it's working normally, and automate state transitions for updates or config changes. Although Helm charts have already solved the challenge of deploying an app and its dependencies, operators go a step further: they're provided by the app's vendor, have intricate knowledge of the workload's requirements, and maintain responsibility for the installation through its entire lifecycle.

It's likely operators will continue to grow in visibility as more complex stateful applications start to offer them. Automating maintenance, "day two" tasks, and upgrades helps to reduce the burden on stretched operations teams and makes it easier for newcomers to get up and running with production-ready deployments.