Skip to main content
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.
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."
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."
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. Helpful references: 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."
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.

Watch Video