Skip to main content
You’ve spent most of this course building an operator. In this section you switch roles: instead of authoring controllers, you learn to consume operators that platform or shared teams install and operate. This shift matters. On real platforms, shared controllers (operators) are frequently installed long before individual teams write their own. Knowing how to consume and integrate these operators is essential for building reliable, maintainable systems on Kubernetes. Two concrete, widely used examples are covered here:
  • cert-manager: exposes Kubernetes APIs such as Issuer, Certificate, and CertificateRequest. Instead of creating TLS Secrets by hand, you declare a Certificate and cert-manager reconciles it into a Kubernetes Secret that applications consume.
  • Prometheus Operator: provides custom resources for running Prometheus and for selecting scrape targets. A ServiceMonitor lets teams describe which services Prometheus should scrape without editing Prometheus’ config directly.
This section explains each operator’s resource model and demonstrates the typical workflow from the operator’s custom resources to the Kubernetes primitives your workloads consume. It also includes a lab combining both operators in the same cluster so you can reason about ownership boundaries—who owns certificates, who owns monitoring, and what your application resources should request or consume.
The image is a diagram illustrating how each operator, "cert-manager" and "Prometheus operator," manages its respective lifecycle (certificate and monitoring), providing results that are consumed by an application.
cert-manager in brief:
  • Primary CRs: Issuer / ClusterIssuer, Certificate, CertificateRequest
  • Outcome: Kubernetes Secret containing TLS material
  • Common issuers: ACME (Let’s Encrypt), HashiCorp Vault, Venafi, self-signed
Prometheus Operator in brief:
  • Primary CRs: Prometheus, ServiceMonitor, PodMonitor, Alertmanager
  • Outcome: Managed Prometheus instances with targets discovered via ServiceMonitor/PodMonitor
  • Benefit: Teams describe scrape targets declaratively without changing Prometheus config directly
Table — Key resources and their purpose
Key learning outcomes: Understand cert-manager’s Issuer → Certificate → Secret flow, learn how ServiceMonitor integrates services with Prometheus, and develop the habit of evaluating operator ownership boundaries before consuming resources.
When consuming operators, ask operational questions up front. These affect security, availability, and upgrade paths:
  • What CRDs does the operator install? (names, versions)
  • Which namespaces does it watch? (single-namespace, multi-namespace, cluster-scoped)
  • What RBAC permissions does it require? (cluster roles, service accounts)
  • What happens when a custom resource is deleted? (finalizers, leftover Secrets)
  • How are upgrades handled? (CRD versioning, migration rules, operator lifecycle)
Table — Operator checklist: what to check and where to look
The image outlines considerations for noticing any operator, including CRDs installation, namespaces watched, required permissions, deletion impact, and upgrade handling. It concludes with a message about consuming operators responsibly.
Before granting an operator broad cluster permissions or creating cluster-scoped CRs, confirm ownership and lifecycle expectations. Operators that own Secrets or Service configurations can impact many teams when misconfigured or upgraded.
What’s next
  • The following sections take a closer look at cert-manager (Issuer → Certificate → Secret) and the Prometheus Operator (Prometheus → ServiceMonitor → scrape targets), with examples and a lab that installs both operators in one cluster. That lab emphasizes reasoning about ownership: cert-manager owns certificate lifecycle, Prometheus Operator owns monitoring lifecycle, and your application resources consume their outputs.
Links & References

Watch Video