DevOps Dictionary

Kubernetes Operator is a Kubernetes controller that automates the lifecycle of an application or infrastructure component using custom Kubernetes resources. In practical terms, it lets you manage complex systems, such as databases, message queues, certificate issuers, or cloud resources, through Kubernetes APIs instead of manual runbooks.

What a Kubernetes Operator does

An Operator encodes operational knowledge into software. It watches Kubernetes resources, compares the current state with the desired state, and takes action to close the gap.

Common responsibilities include:

• Installing and configuring an application
• Creating dependent resources, such as Services, Secrets, PersistentVolumeClaims, or cloud infrastructure
• Scaling application components
• Handling backups, restores, and failover
• Managing upgrades and version changes
• Rotating certificates or credentials
• Repairing drift after a pod, node, or dependency fails

How it works

Most Operators are built around two Kubernetes concepts:

• Custom Resource Definition, or CRD: Extends the Kubernetes API with a new resource type, such as PostgresCluster, Kafka, or Certificate.
• Controller: Runs inside the cluster and watches those custom resources. When a resource changes, the controller reconciles the real system toward the requested state.

For example, a platform team might create a custom resource that says, “run a PostgreSQL cluster with 3 replicas, 100 GiB of storage, and daily backups.” The Operator then creates the required StatefulSets, Services, ConfigMaps, Secrets, storage claims, and backup jobs. If a pod dies, the Operator helps restore the expected state.

Common use cases

• Databases: PostgreSQL, MySQL, MongoDB, Cassandra, and Redis clusters with replication, backups, and failover.
• Messaging systems: Kafka, RabbitMQ, and NATS deployments with topic, user, and cluster management.
• Observability: Prometheus Operator for managing Prometheus, Alertmanager, and ServiceMonitor resources.
• Security and certificates: cert-manager for issuing and renewing TLS certificates.
• Cloud infrastructure: Tools such as Crossplane use the Operator pattern to manage cloud resources through Kubernetes APIs. For example, you can deploy AWS resources using Crossplane on Kubernetes.

Simple example

Without an Operator, running Kafka on Kubernetes often means your team writes scripts and runbooks for broker configuration, persistent storage, rolling upgrades, partition reassignment, user management, and recovery.

With a Kafka Operator, you define a Kafka custom resource. The Operator creates and manages the underlying Kubernetes objects, then keeps watching for changes. If you update the Kafka version in the custom resource, the Operator can perform a controlled rolling upgrade according to its logic.

Benefits

• Less manual work: Repeated operational tasks move into code.
• Consistent operations: Teams use Kubernetes manifests and GitOps workflows instead of ad hoc scripts.
• Better recovery: Operators continuously reconcile state, so they can react when resources drift or fail.
• Self-service for developers: Platform teams can expose safe abstractions, such as a Database resource, while hiding implementation details.
• Declarative infrastructure management: Operators fit naturally with Kubernetes-native workflows, similar to how teams use Terraform for declarative provisioning. If you are comparing approaches, see this guide on how to deploy Kubernetes resources using Terraform.

Tradeoffs and limitations

• Operators add another control plane component: If the Operator has bugs or is misconfigured, it can affect the workloads it manages.
• CRDs can become a long-term API contract: Changing schemas later may require careful migration.
• Debugging can be harder: You need to inspect custom resources, controller logs, events, generated Kubernetes objects, and sometimes external systems.
• Quality varies: Some Operators handle upgrades, backups, and failure cases well. Others only install resources and provide limited lifecycle automation.
• Cluster upgrades need planning: Operators depend on Kubernetes APIs and controller behavior, so include them in your upgrade checks. These practical tips for Kubernetes upgrades are relevant when Operators manage critical workloads.

Kubernetes Operator vs controller

A Kubernetes controller is any component that watches resources and reconciles state. A Kubernetes Operator is a specialized controller that usually manages a complex application or external system using one or more CRDs.

All Operators are controllers, but not every controller is considered an Operator. For example, the built-in Deployment controller manages ReplicaSets and Pods. A PostgreSQL Operator manages a higher-level database system, including Kubernetes resources and database-specific operations.

Kubernetes Operator vs Helm chart

A Helm chart packages Kubernetes manifests and helps install or upgrade them. It usually acts when you run a Helm command or when a GitOps controller syncs the chart.

An Operator keeps running after installation. It watches the cluster and continuously manages the application. Helm is often enough for stateless services. An Operator is more useful when the application needs ongoing lifecycle logic, such as failover, backup scheduling, certificate renewal, or safe version upgrades.

Where Operators fit in platform engineering

Operators are useful when a platform team wants to offer higher-level building blocks through Kubernetes. Instead of asking product teams to manage low-level manifests, the platform team can define custom resources with safe defaults.

For example, a startup platform team might expose a PostgresDatabase resource. Developers request a database in Git, a GitOps tool applies the manifest, and the Operator provisions the database, credentials, backups, and monitoring. The same pattern can extend to cloud services with Crossplane, including workflows that deploy a Kubernetes app with AWS resources using Crossplane.