What is a Kubernetes Operator? Definition & Examples

A Kubernetes operator is an application-specific extension that provides custom objects and control loops to deploy and manage particular software in your cluster, the way a human administrator would. Operators package operational knowledge, such as how to install, upgrade, and maintain an application, into code that runs inside Kubernetes.

Kubernetes itself is an open-source orchestration system for deploying, managing, and scaling containerized applications in distributed environments, and it provides a set of abstractions for defining your apps and their infrastructure. Operators build on those abstractions to simplify the deployment experience for complex software.

In this article, we’ll explore what operators are and why they’re useful, before looking at some prominent examples you might already be using.

We will cover:

1. What are Kubernetes Operators?
2. Kubernetes Operator vs controller
3. Why use Operators?
4. Kubernetes Operator examples
5. How to create a Kubernetes Operator?
6. What is the Operator SDK? 
7. Best practices for writing Kubernetes Operators

An operator is a Kubernetes extension that automates the deployment of an application. Operators typically provide controllers and Custom Resource Definitions (CRDs) that let you rapidly deploy new app instances without deep knowledge of their requirements or how they work.

Operators are intended to reflect the key aims of human administrators. Manually deploying complex systems to a Kubernetes cluster is often intensive because you have to create and connect the Pods, StatefulSets, Services, ConfigMaps, and Volumes that the app requires. Operators let you use custom app-specific object types like postgresql to automate the underlying Kubernetes configuration.

The operator provides the CRDs and accompanying controllers that make this behavior possible. 

The complete Kubernetes architecture combines several components and concepts, but one characteristic binds them together: the system has a declarative state model managed by control loops that automatically apply actions to reconcile your cluster’s actual state with the desired one you configure.

Built-in controllers such as Deployments and ReplicaSets track your cluster’s objects and manage the lifecycle of their dependents. When you create a new three-replica Deployment object using kubectl, the Deployment controller automatically starts a ReplicaSet with three Pods, for example.

Controllers are a general pattern used throughout Kubernetes. They are often part of Operators, a term that describes custom code that integrates specific apps with Kubernetes.

Operators make it easier to deploy and maintain complex apps. The operator provisions the app’s objects for you based on the custom resource configuration you supply. This lets you deploy new apps without any knowledge of Kubernetes objects.

Managing the app’s entire lifecycle

In addition, operators usually manage the app’s entire lifecycle for you, including upgrades, backups, and monitoring integrations. The operator runs the app on your behalf, adding layers of automation that support human administrators as they carry out tedious or error-prone tasks.

Simplifying Kubernetes database deployments

Although you can write an operator for any component in your cluster, they’re most applicable to commonly used persistent systems that require high availability and have their own best practices and configuration requirements. Operators dramatically simplify Kubernetes database deployments, for example, but are unnecessary if you’re simply deploying stateless web servers.

Deploying an instance across many different clusters

Seek an operator when you’re deploying an instance of a general-purpose application that’s routinely used across many different clusters. Don’t create operators for your own codebase unless you’re writing software for others to use that has significant maintenance or configuration requirements. Offering a Helm chart with a sensible set of default values is a better alternative for most use cases.

When not to use an operator

Running an operator is not free. It is another controller to deploy, secure, monitor, and keep compatible with your Kubernetes version, so the operational logic it adds has to be worth that ongoing cost. 

For stateless applications, or anything a Helm chart plus a few sensible defaults already handles, a full operator is usually overkill. Reach for one when an application has real day-two complexity, such as coordinated upgrades, backups, or failover, that genuinely benefits from being encoded in software.

The operator pattern has been widely adopted. Official or community-led operators are available for many popular open-source projects, making it easier to deploy commonly used software components in your stack. Let’s look at four more prominent examples.

Postgres Operator

For example, the Postgres Operator lets you apply the following manifest to start a three-instance, highly available Postgres cluster with 1 Gi of persistent storage per instance, automatic service discovery, and a preconfigured database user account:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
  name: postgres-cluster
spec:
  teamId: "demo"
  volume:
    size: 1Gi
  numberOfInstances: 3
  users:
    demo-user:
      - superuser
      - createdb
  databases:
    demo-user: demo-db
  postgresql:
    version: "17"

The operator creates the StatefulSet, Services, and Volumes for the deployment, but the administrator doesn’t need awareness of these details. They only have to supply the relevant parameters to configure the Postgres cluster.

MySQL Operator

The MySQL Operator for Kubernetes is an official solution for deploying MySQL in Kubernetes. Similar to the Postgres Operator shown above, it lets you provision new MySQL database instances by adding InnoDBCluster objects to your cluster.

The operator automatically manages data persistence, network discovery, and traffic routing by creating appropriate Kubernetes objects such as StatefulSets and Services. It’s designed to accommodate the entire database lifecycle, including future MySQL upgrades and scheduled backups to external object storage systems.

After you’ve installed the operator, you can deploy a new MySQL instance by applying a short YAML manifest to your cluster:

apiVersion: mysql.oracle.com/v2
kind: InnoDBCluster
metadata:
  name: demo-db
spec:
  secretName: mysql-creds
  tlsUseSelfSigned: true
  instances: 3
  router:
    instances: 1

Before using this example, you should follow the guidance in the documentation to create the mysql-creds secret with a database username and password.

Prometheus Operator

The Prometheus Operator deploys and manages instances of the Prometheus time series database, which is commonly used as a Kubernetes observability solution. Prometheus is a cloud-native system composed of several components with complex configuration requirements.

The official operator provides a functional installation for you and offers a useful built-in configuration that scrapes metrics from your cluster environment. You can reconfigure your Prometheus instance by editing custom objects provided by the operator. Without the operator, you’d have to manually synchronize changes to the stack’s components each time a new Prometheus release is issued.

Istio and the Sail Operator

Istio is one of the most popular service mesh implementations for traffic management, observability, and app-aware proxying. For years, Istio shipped an official in-cluster operator that let you configure the mesh by editing a single IstioOperator object. That operator is now a useful lesson in operator lifecycle: Istio deprecated it in version 1.23 and removed it in 1.24, consolidating instead around Helm and istioctl, which account for most of its install base.

Teams that still want the operator pattern for Istio can use the community Sail Operator, which reached general availability in 2025 and manages Istio through custom resources built around Istio’s Helm chart APIs. The takeaway for anyone adopting an operator: like any software, operators have their own lifecycle, so confirm the one you choose is actively maintained and still recommended for your version.

Operators can be authored using any programming language or runtime environment that can interface with the Kubernetes API. Official client libraries are available for languages including C, Go, Java, Python, and Ruby, with community-supported options offered for most other popular choices.

Because operators are a pattern, not a specific set of characteristics, there are several ways in which they can be implemented. Most operators register CRDs that allow users to declaratively express their configuration for the managed app. You then code controllers which use the Kubernetes API to track instances of the CRDs and perform tasks in response.

The operator model has spawned its own set of tools and best practices designed to simplify this process. The Operator Framework is an open-source kit that helps you quickly write stable operators with support for over-the-air updates, dependencies, and simple UI controls. 

It also provides an SDK for building, testing, and packaging operators without having to manually call the Kubernetes API. Operator Framework can be used in Go, Ansible, and Helm projects.

For Go operators specifically, Kubebuilder has become the most widely used framework. The Operator SDK’s Go workflow is built on top of it, and both share the same underlying controller-runtime library, so the concepts carry over directly between them.

The Kubernetes Operator SDK (Software Development Kit) is a toolkit for building Kubernetes Operators. It aims to simplify the process of creating operators for developers without them needing deep knowledge of Kubernetes API complexities.

It supports different languages for creating operators, such as:

• Go – Lets developers to leverage the Go programming language and its ecosystem.
• Ansible – Utilizes Ansible playbooks for Operator logic, making it accessible to a broader range of users, especially those already familiar with Ansible automation.
• Helm – Integrates with Helm charts, enabling developers to build Operators based on existing Helm charts with minimal additional coding

The Operator SDK helps manage the Operator’s entire lifecycle, including installation, upgrades, and management of the application state while allowing the definition of custom resource definitions (CRDs) to the application itself.

It is a part of the Cloud Native Computing Foundation (CNCF), benefiting from a strong community and ecosystem that encourages best practices and collaboration.

When you are creating Kubernetes Operators, there are a couple of best practices that you have to take into account:

1. Define clear CRDs – CRDs should be well-defined with clear specifications as they are the stepping stones of your Operator.
2. Follow Kubernetes API conventions – Adhere to Kubernetes conventions and follow the declarative API model that Kubernetes uses.
3. Handle state properly – Properly manage the state and provide accurate status updates. The status should provide meaningful information that can be used to troubleshoot in case errors occur.
4. Incorporate error handling – Implement error handling wherever possible, as operators should be resilient to failures.
5. Use Kubernetes client libraries – This will ensure compatibility and reduce the effort needed to handle Kubernetes object interactions.
6. Optimize for performance – Avoid excessive API calls, watch for resource leaks, and ensure it scales well with the number of managed resources.
7. Secure your operator – Secure communications with the Kubernetes API server, handling sensitive information (like secrets) appropriately and adhering to the principle of least privilege.
8. Document your operator – Document how to install, configure, and use the Operator, as well as its limitations and how it handles edge cases.

If you need help managing your Kubernetes projects, consider Spacelift. It brings with it a GitOps flow, so your Kubernetes Deployments are synced with your Kubernetes Stacks, and pull requests show you a preview of what they’re planning to change. 

With Spacelift, you get:

• Policies to control what kind of resources engineers can create, what parameters they can have, how many approvals you need for a run, what kind of task you execute, what happens when a pull request is open, and where to send your notifications
• Stack dependencies to build multi-infrastructure automation workflows with dependencies, having the ability to build a workflow that can combine Terraform with Kubernetes, Ansible, and other infrastructure-as-code (IaC) tools such as OpenTofu, Pulumi, and CloudFormation.
• Self-service infrastructure via Blueprints, enabling your developers to do what matters – developing application code while not sacrificing control
• Creature comforts such as contexts (reusable containers for your environment variables, files, and hooks), and the ability to run arbitrary code
• Drift detection and optional remediation

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Operators extend Kubernetes with application-specific functionality. They’re created as external components that use the Kubernetes API to manage objects in your cluster. Operators abstract away the complexities of deploying large stateful applications in Kubernetes, letting you focus on your app’s configuration instead of low-level Kubernetes objects.

In this article, you’ve learned what operators are, the situations where they’re useful, and where to go to get started building your own. Try installing an operator in your cluster to manage the apps you depend on, or head to the Spacelift blog for more Kubernetes guides.