Kubernetes Operator
A custom controller that encodes operational knowledge for a specific application, extending Kubernetes with domain-specific automation.
What is Kubernetes Operator?
A Kubernetes Operator is a software extension to Kubernetes that uses custom resources (CRDs) and custom controllers to manage complex, stateful applications with the same Kubernetes reconciliation model used for built-in resources. The operator pattern was introduced by CoreOS in 2016 to capture the operational knowledge of running databases, message queues, and other stateful systems — knowledge that was previously encoded in runbooks and executed by human operators.
An operator consists of two parts: a CustomResourceDefinition (CRD) that defines the domain-specific API (e.g., PostgresCluster, KafkaTopic, ElasticsearchIndex) and a controller that watches for changes to those custom resources and takes action to reconcile actual state with desired state. For a PostgreSQL operator, this might mean provisioning PVCs, configuring replication, handling failover, taking scheduled backups, and managing schema migrations — all triggered by changes to a PostgresCluster YAML file.
The Operator Framework, OperatorHub, and Kubebuilder are popular tools for building operators. Well-known operators include the Prometheus Operator (manages Prometheus instances and ServiceMonitors), CloudNativePG (PostgreSQL on Kubernetes), Strimzi (Apache Kafka), and cert-manager (TLS certificate management). Operators are typically installed via Helm charts and run as Deployments in a dedicated namespace.
Example
# Install the cert-manager operator
helm install cert-manager jetstack/cert-manager \
--namespace cert-manager --create-namespace \
--set installCRDs=true
# Create a custom resource managed by the operator
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: api-tls
namespace: production
spec:
secretName: api-tls-secret
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- api.example.comCost & Waste Implications
Operators themselves consume cluster resources (typically 100–500m CPU, 128–512Mi memory per operator Deployment). Clusters running many operators — one for each managed service — can accumulate significant fixed overhead, especially in smaller dev clusters where operator overhead is a larger fraction of total cluster cost. Operators also create CRD instances that persist after the managed application is deleted, becoming orphaned custom resources.
How KorPro Helps
KorPro detects operator-created custom resources that have become orphaned (e.g., a PostgresCluster CRD instance persisting after its associated StatefulSet and PVCs were manually deleted) and surfaces the associated storage and compute waste.
Scan Your Cluster FreeRelated Terms
CustomResourceDefinition(CRD)
OperationsAn API extension mechanism that lets you define new resource types in Kubernetes, treated like built-in objects by the API server.
Read definitionHelm
OperationsThe Kubernetes package manager that bundles resource manifests into versioned, configurable charts installable with a single command.
Read definitionDeployment
WorkloadsA controller that manages a ReplicaSet to keep a specified number of identical Pod replicas running and handles rolling updates.
Read definitionOrphaned Resource
FinOpsA Kubernetes resource that is no longer referenced by any active workload but continues to exist in the cluster, often incurring cost.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.