> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Kubernetes Operator Patterns > Explains Kubernetes Operator patterns, using CRDs and controllers to encode SRE runbooks and provide managed, declarative, domain-aware lifecycle automation for stateful platform services. Alright students — welcome to one of the most important topics for the CNPA exam: the Kubernetes Operator pattern. This lesson explains how platform engineering uses Operators to extend Kubernetes beyond containers and basic primitives, enabling managed, stateful, and domain-aware platform services. A blue-green gradient presentation slide titled "Kubernetes Operator Patterns" with the subtitle "Extending Kubernetes for Platform Engineering." It has subtle diagonal geometric shapes in the background. ## Why extend Kubernetes? Kubernetes is commonly used for stateless workloads (Pods, Deployments, Services). Modern platform requirements (databases, ML pipelines, message buses, batch systems) demand richer lifecycle management: backups, failover, leader election, schema migrations, observability, and operational policies. Platform teams want to capture this operational knowledge once and expose simple APIs to developers so teams can consume managed services without needing deep SRE expertise. A slide titled "Why Kubernetes Needs Extension Patterns" showing four numbered points under "2025 Platform Reality": Beyond Basic Resources, Domain-Specific Operations, Operational Knowledge, and Self-Healing Systems. Each box briefly explains the need for richer platform resources, domain-specific workflows, captured operational expertise, and automation for self-healing. Platform teams typically hide operational complexity from developers. At Sparkle Pony Ranch, SREs like Alan and Phong manage domain-specific objects that Kubernetes doesn't natively understand. A one-size-fits-all Deployment model doesn't suit systems like PostgreSQL, Redis, or ML pipelines — each needs custom lifecycle operations. A presentation slide titled "Why Kubernetes Needs Extension Patterns" listing points like PostgreSQL, Redis, and ML pipelines having unique operational needs and that one-size-fits-all deployments don't work. On the left is a dashed box labeled "Sparkle Pony Ranch" with three colorful avatar icons labeled Swati, Alan, and Phuong. ## Operator pattern — concept and value At the core of extensibility are Custom Resource Definitions (CRDs) and controllers: * CRDs: extend the Kubernetes API with new resource types and schemas. * Controllers: continuously reconcile actual state toward the desired state specified by CRs. Together they form the Operator pattern: declarative schema (CRD) + operational behavior (controller). Operators encode human operational runbooks as software. For example, a PostgreSQL Operator not only starts containers but also understands primary/replica roles, performs failover, manages backups and point-in-time recovery, runs schema migration safely, and configures observability. In short: domain expertise as code. A presentation slide titled "Operators — Human Operations Encoded as Software" with a large PostgreSQL elephant logo on the left. Bulleted points on the right list tasks like managing primary-replica setup and failover, handling schema migrations and recovery, and encoding PostgreSQL expertise as software. This model benefits both platform teams and developers: platform engineers (Alan) create complex, reusable objects, and developers (Phong) consume them with simple manifests. The pattern is succinctly: CRDs + controllers = Operator. A slide diagram titled "CRDs + Controllers = Operator Pattern" showing three components: Operator Pattern ("Complete extension solution"), Controllers ("Watch CRDs and implement operational logic"), and Custom Resource Definitions ("Define new Kubernetes resource types"). It explains how CRDs and controllers combine to form the Kubernetes operator pattern. ## Advantages (at a glance) | Benefit | What it enables | | - | - | | Native API integration | Works with `kubectl`, RBAC, admission controllers, and audit logs | | Declarative desired state | Users declare intent; controllers implement it | | Event-driven reconciliation | Controllers react to changes for continuous convergence | | Extensible without core changes | Add domain-specific resources without modifying Kubernetes itself | ## CRDs: defining the API/schema A CRD defines a new resource type and its schema. For example, an operator could define resources under a custom group like `database.spr.com` with Kind `PostgreSQLCluster`. Namespaced CRDs scope each instance to a namespace. A slide titled "Custom Resource Definition – PostgreSQL Cluster" listing two points: "Defines CRDs under the spr.com domain" and "Provides a consistent interface for all database types." On the left is a "Sparkle Pony Ranch" tag and a green circular user avatar labeled "Alan." Note: In `apiextensions.k8s.io/v1` a valid CRD requires a `versions` array and OpenAPI v3 schema (if you want server-side validation). The example below shows a minimal, valid CRD skeleton compatible with `apiextensions.k8s.io/v1`. ```yaml theme={null} apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: postgresqlclusters.database.spr.com spec: group: database.spr.com scope: Namespaced names: plural: postgresqlclusters singular: postgresqlcluster kind: PostgreSQLCluster shortNames: - pgcluster versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object ``` ## Developer experience: a single declarative manifest With a CRD and controller in place, a developer requests managed services using a compact, readable Custom Resource. The Operator reconciles the CR into StatefulSets, Services, PVCs, backups, monitoring, and any external actions. Example developer-facing manifest: ```yaml theme={null} apiVersion: database.spr.com/v1 kind: PostgreSQLCluster metadata: name: pony-analytics-db namespace: magical-creatures spec: version: "15" replicas: 3 storage: "100Gi" backup: schedule: "0 2 * * *" retention: "30d" monitoring: enabled: true ``` A single YAML like this can provision a production-ready PostgreSQL cluster (HA, scheduled backups, monitoring integration). The operator handles the implementation details at reconcile time. A presentation slide titled "Using Custom Resources – Developer Experience." It lists platform values: simple YAML creates production-ready PostgreSQL; high availability, backups, and monitoring are automated; and no need for deep PostgreSQL or infrastructure expertise. ## How controllers work — the reconciliation loop Controllers implement the continuous reconciliation loop: * Watch: watch CR instances and related Kubernetes resources. * Analyze: compare observed state with the desired state. * Reconcile: perform create/update/delete actions to converge state. * Repeat: continue in an event-driven loop (reacts to events and periodic resync). For a `PostgreSQLCluster` controller this could include: * Creating StatefulSets for DB pods * Creating Services (primary and replica access) * Creating ConfigMaps and Secrets * Provisioning PVCs and storage * Configuring replication, leader election, and connection endpoints * Scheduling backup jobs per spec * Registering ServiceMonitor or other monitoring resources Controllers are the place where a CR's schema is mapped to concrete Kubernetes objects and external operations (backups, cloud snapshots, etc.). CNCF provides many operators you can reuse for common platform services: [Prometheus](https://prometheus.io/), [Jaeger](https://www.jaegertracing.io/), [Strimzi (Kafka)](https://strimzi.io/), and [Istio](https://istio.io/), among others. A slide titled "CNCF Operator Landscape" showing four operator cards: Prometheus, Jaeger, Strimzi, and Istio. Each card displays an icon and a brief purpose (monitoring/alerting, distributed tracing, Kafka cluster management, and service mesh lifecycle management). A slide titled "CNCF Operator Landscape" showing three operator frameworks — Operator SDK, Kubebuilder, and KUDO — each with a short description underneath. ## Operator frameworks — summary | Framework | Use case / Notes | Primary languages | | -: | - | - | | Operator SDK | Batteries-included tooling; supports Go, Helm, Ansible operators | Go, Helm, Ansible | | Kubebuilder | Kubernetes SIG toolkit built on controller-runtime; ideal for Go-based operators | Go | | KUDO | Declarative operator framework for simpler stateful apps | YAML-centric / declarative | Most teams choose [Kubebuilder](https://book.kubebuilder.io/) or [Operator SDK](https://sdk.operatorframework.io/) for complex operators depending on language preference and ecosystem familiarity. A slide titled "CNCF Operator Landscape" showing an illustrated avatar labeled "Swati" and a "Sparkle Pony Ranch" box. Three callouts note that CNCF operators deliver managed services, enable self-service through platform catalogs, and offload deployment/config to the Prometheus Operator. ## Scaffolding with Operator SDK Operator SDK scaffolds a project, the API objects, controller code, CRD manifests, and testing/deployment helpers — accelerating development and enforcing common patterns. Example Operator SDK workflow: ```bash theme={null} # Initialize new operator project operator-sdk init --domain=spr.com --repo=github.com/spr/pony-operator # Create API and controller scaffolding operator-sdk create api --group=apps --version=v1 --kind=PonyFarm --resource --controller ``` A slide titled "Building Operators With Operator SDK" listing three points: building custom operators, tailoring them for Sparkle Pony Ranch applications, and automating complex pipelines like pony analytics. On the left is a green avatar labeled "Alan" and a badge for "Sparkle Pony Ranch." ## Case study — Prometheus Operator The Prometheus Operator is a practical example of how Operators provide platform value: * ServiceMonitor CRs discover and configure scrape targets automatically. * PrometheusRule CRs manage recording and alerting rules as code. * Alertmanager CRs enable programmable alert routing and notification channels. * The operator manages Prometheus instances, storage, config, and upgrades. Platform teams deploy the Prometheus Operator once; developers enable monitoring via CR flags and the operator implements discovery, scrape configs, rules, and lifecycle actions consistently. A presentation slide titled "Case Study: Prometheus Operator" with a "Platform Value" panel. It lists three bullets: teams declare monitoring intent (operator handles implementation), automatic service discovery and configuration, and consistent monitoring across all applications. Slide titled "Case Study: Prometheus Operator" showing an avatar for "Swati" at "Sparkle Pony Ranch" with three callouts: deploys Prometheus once for all services, enables automatic monitoring setup, and manages config, discovery, rules, and alerts. ## Key takeaways * Operators = CRDs (API/schema) + controllers (behavior/reconciliation). * Operators let you convert human SRE runbooks into repeatable, automated software. * Use the CNCF ecosystem to adopt ready-made operators or frameworks to build custom ones. * Operators transform Kubernetes into an SRE-enabled platform for domain-specific applications. * For the CNPA exam: understand how operators encapsulate operational knowledge, enable self-service, and provide a consistent platform API. Exam tip: Remember the operator pattern as “CRDs define the API/schema; controllers implement the reconciliation logic.” Operators are how you encode SRE runbooks and operational behavior as software. Thanks for reading this lesson on Operators. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.