> ## 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. # Working Operator Versus Production Operator > Explains how to transform a working Kubernetes operator into a production-ready operator by adding testing, observability, RBAC, upgrade plans, clear status/events, and repeatable packaging for maintainability and trust The key question at the end of an operator project is not just “does it run?” A working operator may reconcile a demo Custom Resource (CR) in a dev environment, but a production-minded operator is one that someone else can explain, observe, upgrade, and trust. The image illustrates the transition from a "Working operator" that "reconciles a demo object" to a "Production-minded operator" that is explained, observed, upgraded, and trusted, ultimately gaining the trust of users.

The image illustrates the transition from a "Working operator" that "reconciles a demo object" to a "Production-minded operator" that is explained, observed, upgraded, and trusted, ultimately gaining the trust of users.

This distinction matters because operators usually become part of other teams’ platforms. A cluster may still accept the YAML, but if the operator is unclear, silent, or hard to recover, platform teams won’t know whether the system is healthy or how to respond. The image shows a diagram with the title "Accepted Is Not the Same as Healthy," illustrating a process involving "Your operator," "Another team," and an outcome labeled "Unclear."

The image shows a diagram with the title "Accepted Is Not the Same as Healthy," illustrating a process involving "Your operator," "Another team," and an outcome labeled "Unclear."

A compact web-app operator is a useful pattern to demonstrate the production shape of an operator without implying the sample project is a finished enterprise product. In this pattern: * The Custom Resource (CR) is the contract describing user intent. * The reconcile loop is the convergence and repair mechanism that turns intent into reality. * Deployments, Services, ConfigMaps, and other Kubernetes resources are the managed “real-world” work. * Status fields and Kubernetes Events are the signals that users and platform operators read to understand changes. Production readiness wraps practical operational concerns around that core loop. The API should stay small and stable. The controller must keep making forward progress as cluster state changes. Deletion should be deliberate and recoverable. Status and events should tell a coherent story. Packaging and deployment must be repeatable so another engineer can run the operator without guessing. The image is a diagram titled "Production Readiness Wraps the Loop," showing a circular flow with elements indicating attributes like "API small and stable," "Keeps making progress," "Deletion deliberate," and "Status tells a story."

The image is a diagram titled "Production Readiness Wraps the Loop," showing a circular flow with elements indicating attributes like "API small and stable," "Keeps making progress," "Deletion deliberate," and "Status tells a story."

These production checks do not replace the code you wrote; they frame and harden it. Tests, permissions, metrics, upgrade plans, and documentation are not “extras” — they are essential practices that make the operator dependable in shared environments. Production-readiness checklist (practical items to include): * Unit and integration tests that validate the reconcile loop and failure cases. * Least-privilege RBAC and a clear, documented permissions model. * Metrics, liveness/readiness probes, and health endpoints for observability. * Upgrade and rollback strategies for both CR schemas and controller versions. * Intuitive status fields and user-facing Kubernetes Events that explain state changes. Below is a compact reference to the operator’s core responsibilities and where to apply production practices. | Component | Role in the operator pattern | Example best practice | | -------------------- | --------------------------------------------: | -------------------------------------------------- | | Custom Resource (CR) | Contract for user intent | Keep schema minimal and versioned | | Reconcile loop | Convergence and repair logic | Test idempotency and error handling | | Managed resources | Real Kubernetes objects the operator controls | Use declarative manifests and ownership | | Status & Events | Signals for users and platform operators | Populate status with actionable messages | | Packaging & Deploy | How operators are delivered and upgraded | Provide reproducible images and Helm/Trait bundles | Helpful references: * [Kubernetes API concepts](https://kubernetes.io/docs/concepts/overview/kubernetes-api/) * [Operator pattern and best practices](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) * [Operators SDK](https://sdk.operatorframework.io/) Carry forward two main ideas. First, the web-app operator proves the core loop: desired state is expressed via a Custom Resource and the controller keeps real resources aligned with that request. Second, production readiness is the discipline of making that loop understandable and trustworthy for the next person who will operate or inherit the system. The image outlines two key ideas: "The core loop, proven," which emphasizes desired to real processes kept in sync, and "Production readiness."

The image outlines two key ideas: "The core loop, proven," which emphasizes desired to real processes kept in sync, and "Production readiness."

Use that lens for the finish line: the web-app operator demonstrates the pattern end-to-end, and production-readiness practices make the operator maintainable, observable, and safe for operators who inherit it.