Kubernetes Operators: what they are (with examples)

To ensure flexibility and scalability, Kubernetes offers limited initial functionality. K8s Operators are software extensions that leverage Kubernetes APIs to extend its behavior. What do you need to know about how they work and what are the concrete benefits?

Kubernetes has an ace up its sleeve that makes it even more useful, powerful, and flexible. That ace is called the Operator. And it is made possible by the fact that Kubernetes was designed from the beginning for automation, which is integrated directly into the very heart of the software. With Kubernetes, in fact, you can automate not only the distribution and execution of workloads but also the way in which Kubernetes itself does it.

This is why Operators are so powerful: they allow complex clusters and systems to operate automatically based on a series of patterns and principles. Operators, in other words, are patterns that allow you to extend the behavior of the cluster without modifying the Kubernetes code thanks to the latter’s APIs, which act as controllers for custom resources.

To understand what an Operator is for, you first need to understand what it is, which means understanding how Kubernetes works and why Operators are so useful.

Why Kubernetes needs Operators

If you are reading this article, you probably already know Kubernetes. Let’s just do a quick review to understand how Operators fit into its logic.

Kubernetes is open source software for container orchestration, used to automate the deployment, scaling, and management of containerized workloads. Created by Google in 2014 — inspired by its own workload orchestration system, Borg — Kubernetes was donated to the Cloud Native Computing Foundation. The latter, part of the Linux Foundation, now maintains and develops it alongside other large companies like Microsoft and Red Hat.

Kubernetes follows two basic principles: simplicity and flexibility on one hand, and the possibility of making as many functions automatic as possible on the other. These are its main strengths that make it capable of scaling and being usable in extremely diverse contexts and with different applications.

However, these same principles also limit its initial functionality to a narrow set of commands and operations that are exposed through APIs. To do more complex things, this set must be extended and more sophisticated automations must be created, suitable for individual applications and their specific domain of action. This is where Operators come into play.

Kubernetes Operators manage application logic and are part of the Kubernetes control plane. As such, they are controllers that run loops to check the actual state of the cluster and the desired state, acting to reconcile them when the two states are drifting apart. Simplicity and flexibility plus automation not only allow for the creation of Operators but are the basic principles that constitute the cornerstones of the Kubernetes architecture.

What is a Kubernetes Operator

The concept of the Operator was introduced in 2016 by the CoreOS Linux development team (later Container Linux).

The definition of Operator provided by the Kubernetes project itself is simple: “Operators are software extensions that use custom resources to manage applications and their components”. This means that by using Operators, it is possible to consider an application, rather than as a set of primitives (such as Pods, Deployments, Services, or ConfigMaps), as a single object that exposes only the settings that make sense for the application.

We can say more, because in reality Operators allow for the automatic implementation of typical Day-1 activities (installation, configuration, etc.) and Day-2 activities (reconfiguration, update, backup, failover, recovery, etc.) for software running within the Kubernetes cluster, integrating natively with Kubernetes concepts and APIs.

This is why they are called “Kubernetes-native applications”. This definition can also be seen in another, more operational way. K8s Operators are controllers for packaging, managing, and deploying applications on Kubernetes. To do this, the Operator uses Custom Resources (CR) that define the configuration and desired state of a specific application through Custom Resource Definitions (CRD).

The role of the Operator is to reconcile the actual state of the application with the state desired by the CRD using a control loop in which it can automatically scale, update, or restart the application. In practice, Kubernetes offers basic commands, primitives, which can be used by Operators to define more complex actions.

Ultimately, Operators are actual programs that run in the cluster and interact via Kubernetes APIs to automate functions more complex than those natively managed by Kubernetes itself.

Read also: Kubernetes: what are the benefits for companies

K8s Operator: what it is for and what problems it solves

If all this sounds like automatic software for system administration, well, you’re right. An Operator, if you will, is exactly that: an expert to whom we indicate what we want and with what tools, and who then works incessantly to achieve that goal.

From this point of view, Operators are declarative and not imperative tools, because our role is to define the objectives and desired resources while their responsibility is to adjust the system to keep it as close as possible to the desired state.

The number of things that can be automated via an Operator is almost infinite, although there are some typical operations that are most common.

• The ability to perform on-demand deployment of an application;
• Performing backups of an application’s state or restarting from a specific backup;
• Managing application updates with all their dependencies, including new configuration settings and necessary database changes;
• Exposing a service to applications that do not support Kubernetes APIs.

These are just some of the possible applications of K8s Operators. The limit of what can be done with Operators is linked to the skills of those who program them and the needs of the project.

Put it this way: compared to Kubernetes, which allows you to manage an application using its APIs (and kubectl), an Operator is a controller that extends API functionality and manages complex instances of the application on behalf of the user. To do this, it uses Kubernetes’ own resources on one hand and specific expertise for that particular application or domain on the other.

In this way, Operators serve to automate the entire lifecycle of the software they manage, taking charge of the classic Day-1 and Day-2 activities that, without automation, would be tasks for one or more human operators.

The advantages of Kubernetes Operators

Operators are very useful because they are controllers specific to a single application, which extend the functionality of Kubernetes APIs. In other words, Operators teach Kubernetes new tricks. But what are the concrete advantages they offer? Let’s look at a list of the main benefits.

1. Operators allow for extending Kubernetes functionality to stateful applications as well, not just stateless ones. And this is already a significant advantage, because stateful cloud applications and services are much more complex to manage than stateless ones. Among stateful operators, we can highlight: Prometheus Operator for the monitoring solution and Postgres Operator for managing high-availability PostgreSQL database clusters.
2. They standardize manual activities and create a common and consistent approach to automation.
3. Operators can be easily transported from one environment to another and from one project to another. This has allowed for the birth of an ecosystem with many generic Operators that can be downloaded, configured, and used for different projects without the need to develop them internally. Later we will see which are the most popular hubs for finding generic Operators.

This last advantage should not be underestimated. In fact, creating an Operator from scratch is not exactly easy. Fortunately, there are several alternatives.

Best practice 2026

Whenever possible, it is advisable to limit the scope of Operators to a single namespace rather than granting access to the entire cluster. This approach reduces the attack surface, simplifies RBAC permission management, and minimizes the impact of any malfunctions, while maintaining greater isolation between different teams and projects sharing the same Kubernetes cluster.

The issue of security deserves special attention, because this is precisely where many Operators¹ introduce often underestimated risks. To automate deployment, state reconciliation, and custom resource management, an Operator requires permissions that, if poorly calibrated, become a weak point: many operators distributed via Helm charts or OLM require a ClusterRole by default with broad verbs (get, list, watch, create, update, delete) on cluster-wide resources. A compromised Operator, or one affected by a bug in the reconciliation logic, inherits those privileges and can act on every namespace, including other teams’ secrets.

The difference between the two RBAC² authorization models has a direct impact on the blast radius in the event of an incident:

The path a request follows from the Operator to the action on the cluster helps to understand where to intervene to apply the principle of least privilege:

From our experience on multi-tenant clusters, the most effective countermeasure is not to eliminate ClusterRoles, which remain necessary for platform Operators, but to apply three concrete practices: assign each Operator a dedicated ServiceAccount instead of reusing the default one, reduce RBAC verbs to the absolute minimum avoiding wildcards (*), and verify third-party Operator manifests before installation, as default chart values tend to be permissive to maximize compatibility. Tools like kubectl auth can-i --list for the specific ServiceAccount, or policy engines like Kyverno and OPA Gatekeeper, allow this verification to be an integral part of the pipeline rather than a one-time manual check.

Prefabricated Operators and custom solutions

Operators are decidedly complex to create from scratch. They require programming skills (preferably Go³, but they can be implemented in any language as they involve client/server communications) and in-depth knowledge of native Kubernetes controllers⁴ and its operating mechanisms (reconciliation loop). For development in Go, the de facto standard today is the Operator SDK, part of the Operator Framework: it handles much of the reconciliation loop boilerplate and simplifies scaffolding, testing, and packaging of Operators, reducing the barrier to entry for those who do not want to start from native controllers.

However, there are frameworks that allow for reducing this complexity, such as:

• Operator Framework⁵
• Kubebuilder⁶
• Kubernetes Operators Framework⁷

Fortunately, as we have seen, Operators can be transferred from one environment to another and configured easily. For this reason, a true cottage industry has emerged with the aim of enriching and simplifying the deployment, management, and scaling operations of applications on Kubernetes via Operators.

Kubernetes Operators: some examples

To date, the official sources where you can easily search for existing Operators are these two applications:

• Artifact HUB — where we find both operators and helm charts (CNCF project)
• Operator Hub — dedicated exclusively to Operators (Red Hat project)

Operators allow us to find solutions to very different problems. Instead of a list of Operators, let’s start from some situations to solve and give some examples.

An emblematic case is scaling based on external events. The native Kubernetes Horizontal Pod Autoscaler reasons on metrics like CPU and memory, but these rarely reflect the actual load of an event-driven workload: a consumer processing messages from a queue can remain at low CPU usage even with thousands of backlogged messages. KEDA (Kubernetes Event-driven Autoscaling) solves exactly this gap. It is a CNCF project (graduated in 2023) that acts as an Operator: it introduces the ScaledObject Custom Resource and, through a set of ready-to-use scalers, reads metrics from external sources like Kafka, RabbitMQ, Prometheus, AWS SQS, or Azure Service Bus, translating them into scaling decisions.

The most interesting and often underestimated feature is the scale-to-zero capability: when there are no events to process, KEDA brings the deployment replicas to zero, only to reactivate them as soon as the first message arrives. This makes it particularly effective from a FinOps perspective for intermittent workloads like batch jobs, asynchronous processing pipelines, or self-hosted serverless functions, where paying for inactive pods is pure waste.

From an architectural point of view, KEDA does not replace the HPA but extends it: it acts as a metrics adapter, feeding the native autoscaler with values collected by the scalers. This means that adoption is incremental and does not require rewriting existing deployment logic, an aspect we appreciate when introducing event-driven scaling in clusters already in production.

Do you want to monitor your cluster?

A very efficient end-to-end solution for monitoring the Kubernetes cluster is based on the kube-prometheus stack. This is a collection of Kubernetes manifests, Grafana dashboards, and Prometheus rules combined with documentation and scripts that provide easy-to-use monitoring by leveraging the Prometheus Operator.

Do you want to automate TLS certificate management

In this case, we can use Cert-manager⁸, the Kubernetes add-on that allows for obtaining SSL/TLS certificates issued by a list of certification authorities configured in the cluster. In this way, new certificates can be requested on the fly from each of the issuers and used in the service lifecycle automatically, with native support for both Ingress and the more recent Gateway API.

Do you want to automate the management of an Istio-based service mesh

The Istio Operator⁹ was the historical approach to automatically install, update, and manage Istio configurations¹⁰ directly from the cluster. Today, however, this method is deprecated: the in-cluster operator was declared deprecated in Istio 1.23 and removed starting from 1.24. For new projects, therefore, service mesh installation and management should be entrusted to Helm¹¹ or istioctl¹², which remain the supported and recommended tools for managing the Istio lifecycle and validating the relative APIs. The community is moving towards leaner installation models and, above all, towards the Ambient Mesh¹³ architecture, which eliminates the need to inject a sidecar for each pod and moves traffic management to a shared infrastructural level, reducing overhead and operational complexity.

Use in both DevOps and SRE scenarios allows for automating from the start the mesh management of microservices used in the Kubernetes cluster: management, orchestration, security, communications, and monitoring. After that, this initial implementation can be refined in a non-traumatic way.

An increasingly relevant piece of this automation is the Kubernetes Gateway API, the evolution of Ingress designed to overcome its historical limits: monolithic configuration, dependence on proprietary annotations, and the absence of a clear separation of roles between those who manage the cluster and those who expose services. The Gateway API introduces distinct resources (GatewayClass, Gateway, HTTPRoute, GRPCRoute) that formalize that separation of responsibilities useful in DevOps and SRE teams, and that fits naturally with mesh traffic management.

The clearest signal of this standard’s maturity comes from the operators that have historically defined the network layer on Kubernetes. Cilium implements the Gateway API leveraging the data plane based on eBPF and Envoy, offering L7 routing, traffic splitting, and TLS termination without a separate Ingress controller. Istio, for its part, has elected the Gateway API as the default traffic ingress configuration method, relegating the old Gateway and VirtualService resources of its own API set to the role of a legacy alternative. The direction is clear: Ingress support is maintained for backward compatibility, but investment and new features converge on the Gateway API.

For those designing a mesh architecture today, this means being able to adopt a single portable abstraction between different providers and implementations, reducing the risk of vendor lock-in linked to the specific annotations of each Ingress controller.

Automating the creation of resources on public cloud

Crossplane¹⁴ is a Kubernetes Operator that allows for creating and managing cloud resources via Kubernetes declarative syntax, mapping a collection of CRDs, provided by crossplane-providers, with the cloud services offered by the specific vendor. All this is aimed at use by application teams, who do not need to write any code to do so. It is, in practice, about automating the creation of resources on the public cloud.

As the authors of the project, which is part of the CNCF, explain: “ we created Crossplane to help organizations build their own clouds like cloud providers build theirs: with a control plane.”

How to manage Elastic Cloud in our cluster

The Elastic Kubernetes Operator — officially created by the Elastic project — allows for automating Elasticsearch and Kibana on Kubernetes with very simplified deployment configurations and easy management. The Operator supports both Frozen Indices for larger storage sizes and Kibana Spaces, Canvas, and Elastic Maps, plus the Kubernetes infrastructure monitoring part.

Conclusions

As we have said, the Operators we have seen so far are just a few examples. Many other Operators exist: from KNative¹⁵ to Cloud Foundry on Kubernetes¹⁶ to Azure Spring Cloud, now renamed Azure Spring Apps¹⁷, ¹⁸. And obviously, there are Operators for many other popular types of services and applications: Grafana, Jaeger¹⁹, ArgoCD²⁰, MongoDB, Rbac (Role-Based Access Control).

In 2026, the Operator ecosystem has reached full maturity: OperatorHub now collects hundreds of certified solutions, and major databases, message brokers, and observability platforms distribute their own Operator as the default installation method. For most production use cases, it is no longer necessary to write an Operator from scratch, but rather to evaluate and adopt the right one from the available options.

In all cases, however, although very different from each other, the same principle always applies. The advantage of Operators is to expand the automation possibilities of Kubernetes. The presence of a large ecosystem of K8s Operators allows for finding ready-made solutions for most use cases.

Notes and sources