The Operator Pattern: A Robot SRE for Your App

The Operator pattern adds a custom, automated "robot SRE" to your Kubernetes cluster. It encodes human operational knowledge for a specific application, like a database, into software that handles complex tasks like upgrades, backups, and failovers…
WHY IT EXISTS Kubernetes is great at managing stateless apps, but complex stateful apps like databases require specific operational knowledge for tasks like backups, upgrades, and failovers. The Operator pattern was created to automate this domain-specific knowledge, which is difficult to express with standard Kubernetes objects alone.
THE MENTAL MODEL Think of an Operator as a robot Site Reliability Engineer (SRE) that lives inside your cluster. You give it the runbook for your application (e.g., "how to safely upgrade a Postgres cluster"), and it executes those steps automatically. It extends the Kubernetes API with custom resources, letting you manage your app declaratively, just like a built-in resource.
HOW IT WORKS An Operator combines two key Kubernetes features. First, a Custom Resource Definition (CRD) defines a new object type, like kind: PostgresCluster. Second, a custom controller (the Operator itself, a program running in a Pod) watches for these new objects. When you create a PostgresCluster resource, the controller sees it and performs the necessary actions—creating StatefulSets, Services, and ConfigMaps—to bring the database to life. It then continuously monitors the state, reconciling any differences between your desired state and the actual state in the cluster.
WHEN TO USE IT Use the Operator pattern for applications with a complex lifecycle that can't be managed by standard Deployments or StatefulSets. It's ideal for databases, message brokers, and monitoring systems that you want to run natively on Kubernetes with automated day-2 operations (like backups and scaling).
WHEN NOT TO USE IT Do not build or use an Operator for a simple, stateless application. A standard Deployment and Service are far simpler and sufficient. Building a robust Operator is a significant engineering effort, and using a complex one adds operational overhead. A Helm chart is often a better choice for simple application packaging.
ONE CANONICAL EXAMPLE The Prometheus Operator. Instead of manually configuring Prometheus servers, you create a Prometheus custom resource. The Operator then automatically deploys and configures Prometheus. To monitor a new service, you just create a ServiceMonitor resource, and the Operator automatically updates the Prometheus configuration to start scraping it.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.