This article draws on expert commentary originally published at enterprisersproject.com.
Why Kubernetes Operators Matter
One of Kubernetes’ core promises is the automation of operational toil — the repetitive, error-prone work that comes with running modern applications at scale. Kubernetes Operators are the mechanism through which that promise is fulfilled. Without them, teams running complex containerized workloads are leaving significant automation potential on the table.
What Is a Kubernetes Operator?
An Operator is a Kubernetes-native application that extends the Kubernetes API to manage custom resources. In practice, this means encoding the operational knowledge of a human expert — runbooks, procedures, and decision logic — into software that runs continuously inside your cluster.
“Operators are clients of the Kubernetes API that control custom resources. This capability enables automation of tasks like deployments, backups, and upgrades by watching events without editing Kubernetes code.”
— Matthew Dresden, Director of DevOps, Nexient
The key differentiator of the Operator pattern — as opposed to a simple Helm chart or a static manifest — is active, ongoing management. An Operator watches the current state of a resource, compares it to the desired state, and takes action to reconcile the two. That includes handling failover, triggering backups, orchestrating rolling upgrades, and autoscaling — behaviors that would otherwise require a human operator on call.
A Concrete Example
Consider a distributed database cluster running on Kubernetes. If the cluster loses a node, a properly written Operator can automatically detect the event through the Kubernetes watch API, replicate data from a healthy node, and restore the cluster to quorum — all without human intervention.
Dresden frames the stakes clearly: imagine managing a highly available, fault-tolerant, multi-region database using StatefulSets, while simultaneously running several hundred microservices that scale dynamically. Coordinating that manually is not realistic for most teams. Operators make it manageable.
“Operators make large-scale Kubernetes deployments practical by automating difficult, error-prone work that humans — the original ‘operators’ — would otherwise need to carry out.”
— Matthew Dresden, Nexient
4 Facts IT Leaders Should Know About Kubernetes Operators
1. Operators Are Growing Rapidly in Quantity and Adoption
CoreOS first introduced the Operator pattern in 2016. Adoption accelerated significantly with the launch of the Operator Framework in March 2018. Red Hat acquired CoreOS in January 2018 and has since integrated Operator support deeply into the OpenShift platform.
By the time this article was originally published (early 2020), growth was already notable at the ecosystem level. Liz Rice, then VP of Open Source Engineering at Aqua Security and chair of the CNCF Technical Oversight Committee, observed an “explosion” in the number of Operators being built by project maintainers and vendors — making it easier to deploy popular open-source projects inside a Kubernetes cluster.
This proliferation led to the need for discoverability tooling. OperatorHub.io was launched as a community hub where teams can find, share, and install Operators. It was launched by Red Hat in collaboration with Amazon, Microsoft, and Google.
2. Operators Require Ongoing Attention — They Are Not “Set and Forget”
A common misconception is that deploying an Operator transfers all operational responsibility to software. It does not. Operators themselves are software, and like all software they need to be patched, upgraded, and monitored.
“Kubernetes Operators can and will get into weird states that require hands-on attention. Don’t come in thinking that using Kubernetes Operators is a ‘set-it-and-forget’ type of situation.”
— Ben Bromhead, CTO, Instaclustr
Bromhead recommends establishing a clear ownership and escalation workflow for Operators before they reach production. Developer teams managing Operators in-house must track upstream changes, plan for upgrades, and have a procedure for manual intervention when the Operator enters an unexpected state.
Dresden reinforces this: an Operator is not a one-time artifact. “Continuous improvement is a must,” he says. Automating complexity does not eliminate it — it moves it. Problems will still surface, often at the worst possible moment, and the pace of automated change can make it impossible for a human to manually track state across the system.
3. Telemetry and Observability Are Non-Negotiable
Because Operators act autonomously and can change system state at high frequency, comprehensive observability is essential. Without it, the first indication of a problem is often a customer complaint rather than a proactive alert.
Dresden stresses that both the providers of a managed service (the team that wrote the Operator) and the consumers (the teams running workloads under it) need visibility into what the Operator is doing at any given moment. Metrics, logs, and events emitted by the Operator should be treated as first-class telemetry signals — routed into your existing monitoring stack and covered by alerting rules.
“Operators can generate a huge boost in productivity, but only if both the providers and consumers of the managed service have visibility into what the Operators are doing.”
— Matthew Dresden, Nexient
4. Write Declarative Operators, Not Imperative Ones
Dresden flags a common beginner mistake: writing Operators imperatively — that is, encoding a sequence of steps to execute — rather than declaratively — encoding the desired state and letting the reconciliation loop figure out how to get there.
Declarative Operators align with the Kubernetes control-plane model and are significantly more robust. An imperative Operator that issues a specific sequence of API calls can fail in unpredictable ways if any step is interrupted or if the cluster is in an unexpected state. A declarative Operator that continuously reconciles actual state toward desired state handles partial failures gracefully and is much easier to reason about and test.
Writing a proper declarative Operator takes more upfront design work, but the long-term reliability and maintainability gains are well worth the investment — especially in production environments where reliability directly affects customer experience.
Key Takeaways for DevOps and Platform Teams
- Operators encode operational knowledge as code. They watch cluster state and take autonomous action to maintain desired state — handling backups, failover, scaling, and upgrades.
- The Operator ecosystem is large and growing. Check OperatorHub.io before building a custom Operator — a community-maintained one may already exist for your use case.
- Treat your Operators as production software. They need patch management, upgrade planning, and an escalation path for when they enter unexpected states.
- Invest in observability from day one. Instrument your Operators to emit useful metrics, logs, and events that integrate with your monitoring stack.
- Design declaratively. A reconciliation-loop-based approach is more resilient than imperative step-by-step automation and aligns with how Kubernetes itself works.
Kubernetes Operators are not a silver bullet, but for teams running stateful, complex workloads at scale, they represent one of the most powerful tools available for reducing operational toil and achieving genuine, self-managing automation.