Operating complex systems without Kubernetes operators? Are you really still doing that in 2026?

Why are operators important in Kubernetes?

Kubernetes has established itself as the de facto standard for orchestrating containers. Workloads can be packed into pods, scaled with deployments, and made accessible via services. But when it comes to complex, stateful or highly integrated systems, such as databases, monitoring stacks or messaging platforms, classic Kubernetes objects quickly reach their limits. This is exactly where the operator pattern comes in.

A Kubernetes operator extends Kubernetes itself with ‘expertise’ about a specific application. It automates tasks that would otherwise be performed manually by human experts – from installation and updates to configuration and troubleshooting. The following explains how this approach works, what advantages it offers for development and operation, and how it can be used in practice using the example of Prometheus configuration. Finally, we highlight the business benefits that go far beyond the technology itself.

What is the operator pattern?

The operator pattern is based on two core ideas: custom resource definitions (CRDs) and a controller.

Custom resource definitions (CRDs)

CRDs allow Kubernetes to be extended with custom resource types – similar to deployments or services, but domain-specific. Instead of just deployment or service, there are then resources such as Prometheus, KafkaCluster or PostgresCluster.

These resources describe the desired target state (‘I want a Prometheus cluster with three replicas, these labels, that storage configuration’). Kubernetes itself knows nothing about the semantics of these new resource types, but it can manage and store them.

Controller (the actual operator)

The operator is a specially programmed controller that constantly compares the current state of the environment with the target state described in the CRDs. It reacts to changes when a new Prometheus instance is created or an existing one is modified and then performs the necessary steps: creating deployments, adjusting ConfigMaps, creating services, performing upgrades and much more.

The key point is that this logic contains the operational know-how that used to be stored in runbooks, wiki pages and in the minds of experts.

The interaction between CRD (declaration of the desired state) and operator (implementation of the path to get there) is at the heart of the operator pattern. Kubernetes thus transforms from a generic platform into a system that ‘understands’ specific products and solutions and can operate them independently.

How operators work: from desired state to automation

The core principle of Kubernetes is the concept of the ‘desired state’: instead of prescribing in detail how something should be done, you only describe what the system should look like in the end. The scheduler, various controllers and the Kubelet then ensure that reality and the target state are aligned – this is known as Kubernetes reconciliation.

The operator pattern extends this principle:

• Declarative specification: A CRD describes the target state of a complex application – such as Prometheus with Alertmanager, sharding, retention and storage classes.
• Reconciliation loop: The operator runs in an endless loop: it reads the CRDs, checks the current state in the cluster and performs actions to correct deviations. This can involve creating pods, adjusting configurations or rolling out a new version.

Domain-specific intelligence

The operator ‘knows’ how to perform an upgrade safely, how to set up backups, which dependencies to consider and which best practices apply. Instead of having to obtain scripts and checklists, this knowledge is cast into code.

For developers, this means they can interact with complex systems as if they were native Kubernetes resources – without having to understand all the internal complexity.

Technical advantages for development and operations

From a technical perspective, the operator pattern offers several clear advantages:

• Standardised interfaces: Everything can be controlled using familiar Kubernetes tools: kubectl, YAML manifests, Helm, or GitOps tools such as Argo CD and Flux. This reduces the number of special CLIs and proprietary APIs that teams need to master.
• Less boilerplate and configuration effort: The operator takes care of many recurring configuration details. Default values, best practices, and integrations (e.g., service discovery, TLS configuration, persistent volumes) are already implemented and only need to be parameterised.
• Automated Day 2 operations: Tasks such as rolling upgrades, scaling, self-healing, backup/restore or certificate rotation can be orchestrated by the operator. This reduces manual work and the likelihood of errors during operation.
• Better consistency and repeatability: Since the target state is described declaratively, installation is reproducible. Whether in a test, staging or production environment, the operator ensures that the system is set up according to the same specification.

Practical example: Prometheus in a few steps with an operator

Prometheus is a widely used monitoring system, but its manual configuration can quickly become complex: deployment, service, config files, relabeling, service discovery – everything needs to be neatly orchestrated. The Prometheus Operator (known from the Prometheus Operator project or as part of kube-prometheus) significantly reduces this complexity.

How the Prometheus Operator abstracts

The Prometheus Operator introduces several CRDs, for example:

• Prometheus: Describes one or more Prometheus instances (replicas, resources, storage, etc.).
• Alertmanager: For Alertmanager instances.
• PodMonitor: Analogous for pod-specific endpoints. Instead of writing Prometheus configuration files yourself, you define what is to be monitored in Kubernetes resources. The operator generates the actual Prometheus configuration from this.
• ServiceMonitor: Describes which Kubernetes services are to be monitored by Prometheus.

Quickly configure Prometheus for an application

Assuming your application is deployed in a deployment called my-app in the production namespace and provides metrics at /metrics on port 8080.

1. Create a service for the application (if it does not already exist)

The service ensures that Prometheus can find the application via Kubernetes service discovery.

apiVersion: v1
kind: Service
metadata:
name: my-app
namespace: production
labels:
app.kubernetes.io/name: my-app-srv
app.kubernetes.io/component: my-app
spec:
selector:
app.kubernetes.io/name: my-app
ports:
- name: http
port: 80
targetPort: 8080

2. Define CRD ServiceMonitor

Instead of editing the Prometheus configuration file directly, create a ServiceMonitor object:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app-sm
namespace: production
labels:
app.kubernetes.io/component: my-app
release: prometheus-stack
spec:
namespaceSelector:
matchNames:
- production
selector:
matchLabels:
app.kubernetes.io/name: my-app-srv
endpoints:
- port: http
path: /metrics
interval: 15s

With this single manifest, you tell Prometheus: ‘Please collect metrics from all services with label name=my-app-srv in the production namespace via the http port every 15 seconds.’ The ServiceMonitor resource should be part of the business application so that Prometheus automatically discovers it once it is deployed.

3. Deploy Prometheus instance (typically once per cluster/environment)

The details may vary, but in simplified terms, a Prometheus resource looks like this, for example:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: k8s
namespace: monitoring
spec:
replicas: 2
serviceMonitorSelector:
matchLabels:
release: prometheus-stack
resources:
requests:
memory: "2Gi"
cpu: "500m"

The operator now ensures that:

A StatefulSet for Prometheus with two replicas is created, the appropriate ConfigMaps and services are created, and all ServiceMonitor resources with the label release=prometheus-stack are automatically included in the Prometheus configuration. Alternatively, Prometheus can also be set up so that all ServiceMonitors can be included.

Result:

With just a few declarative YAML files, you have a Prometheus instance that automatically collects metrics from your application. Changes – e.g. an additional ServiceMonitor – are recognised by the operator and applied without manual intervention in the Prometheus configuration. This shows how the operator pattern turns complex operational tasks into a manageable, declarative configuration.

Business benefits: More than just technical elegance

Beyond the technical aspects, the operator pattern has tangible business implications.

Faster time-to-market

New services or platform components can be deployed much faster because much of the infrastructure and operational logic is already encoded in the operator. Teams can activate productive monitoring stacks, databases or messaging systems with just a few manifests, instead of spending weeks building up expert knowledge. This speeds up the rollout of new products and features.

Reduced operating and personnel costs

By automating recurring tasks, the manual effort required for operation is reduced: Fewer night-time shifts for error-prone upgrades, fewer manual configuration changes across different environments, less coordination between development, operations and security for standard tasks. This allows existing teams to manage more systems without growing linearly. This has a direct impact on OPEX (operating expenditures).

Less dependence on individuals

Know-how about the operation of critical systems is often stored in the minds of individual experts. If someone is absent or leaves the company, knowledge gaps and risks arise. By encoding operational knowledge in operators, it becomes replicable, documented and versioned. This reduces ‘bus factor’ risks and facilitates the handover to new colleagues or external partners.

Higher quality and stability

Automated, declarative processes are less prone to errors than manual interventions. The results are fewer configuration errors, more stable upgrades, and consistent setups across all environments. Fewer incidents and shorter downtimes mean greater availability for customers and, ultimately, higher satisfaction and revenue security.

Better compliance and governance

Since operators process declarative configurations and changes are traceable (e.g. via GitOps), compliance requirements are easier to meet: all changes to critical systems are auditable, security and operating guidelines can be firmly anchored in CRDs and operator logic, and certificates, encryption and access rules are implemented consistently.

This facilitates audits, reduces regulatory risks and increases the trust of customers and partners.

Basis for platform strategies

Many companies are developing internal developer platforms to provide self-service capabilities to business units and developers. Operators are a central component of such platforms:

Complex services (e.g. ‘monitoring for a new application’, ‘database instance’, ‘message queue’) can be provided as abstracted self-service offerings. Behind the scenes, operators ensure that provisioning is standardised, secure and compliant. This significantly shortens the path to Platform-as-a-Service within your own company.

Conclusion

The operator pattern transforms Kubernetes from a pure container orchestration platform into a versatile operating platform for complex applications and services. Technically, it enables the automation of operational knowledge, the standardisation of configurations and the reproducible mapping of Day 2 operations. The Prometheus example shows specifically how powerful monitoring for applications can be set up with just a few declarative resources.

At the business level, this approach pays off in the form of faster time-to-market, reduced operating costs, less dependence on individuals, greater stability, and better compliance. For companies that use Kubernetes strategically, the operator pattern is therefore not just a technical pattern, but an important building block of their digital transformation and platform strategy.