> ## 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. # Demo Reading Operator Status and Conditions > Guide to reading operator status, conditions, and events to diagnose and troubleshoot Kubernetes operators using cert-manager examples. CRDs (CustomResourceDefinitions) define your API surface, but what actually acts on those custom resources? Operators do. An operator is a controller: a piece of software that watches custom resources and reconciles cluster state to match the desired state you declared. For example, you create a Certificate custom resource and the operator provisions the actual TLS certificate; when you delete the Certificate resource, the operator cleans up the associated artifacts. This guide shows how to read operator-reported status and conditions so you can diagnose operator behavior without access to its source code. We use cert-manager as a concrete example. Why this matters: * Operators continuously reconcile desired state; reading Conditions and Events is the first step in troubleshooting. * Understanding the status fields tells you whether the operator succeeded, is still working, or failed. CRDs that cert-manager installs | CRD | Role | | - | - | | `Certificate` | Request and manage TLS certificates. | | `Issuer` | Defines how certificates are issued (self-signed, ACME, CA, etc.). | | `CertificateRequest` | Records a single certificate issuance attempt. | | `Order` | ACME order resource for certificate issuance steps. | | `Challenge` | ACME challenge resource used to prove domain ownership. | To issue a certificate you need: * an Issuer (defines how the certificate is issued), and * a Certificate (defines what you want). Below we create a self-signed Issuer (good for testing) and a Certificate that references it, then inspect the operator-reported conditions. Describe the Issuer to confirm the operator processed it and marked it Ready: ```bash theme={null} $ kubectl describe issuer selfsigned-issuer -n operator-lab Name: selfsigned-issuer Namespace: operator-lab Labels: Annotations: API Version: cert-manager.io/v1 Kind: Issuer Metadata: Creation Timestamp: 2026-04-11T10:12:02Z Generation: 1 Resource Version: 5784 UID: 458e9c3f-5f76-4ddc-8651-a6895b2080cb Spec: Self Signed: Status: Conditions: Last Transition Time: 2026-04-11T10:12:02Z Observed Generation: 1 Reason: IsReady Status: True Type: Ready Events: ``` Apply a Certificate resource. Example `test-certificate.yaml`: ```yaml theme={null} apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: test-cert namespace: operator-lab spec: secretName: test-cert-tls duration: 2160h # 90 days renewBefore: 360h # 15 days before expiry subject: organizations: - Example Corp commonName: test.example.com dnsNames: - test.example.com - www.test.example.com issuerRef: name: selfsigned-issuer kind: Issuer ``` Apply the Certificate and check its status: ```bash theme={null} $ kubectl apply -f test-certificate.yaml certificate.cert-manager.io/test-cert created $ kubectl get certificate -n operator-lab NAME READY SECRET AGE test-cert True test-cert-tls 18s ``` Describe the Certificate to read the operator-reported Conditions, human-readable messages, validity window, renewal time, and Events showing reconciliation steps: ```bash theme={null} $ kubectl describe certificate test-cert -n operator-lab Name: test-cert Namespace: operator-lab Labels: Annotations: API Version: cert-manager.io/v1 Kind: Certificate Metadata: Creation Timestamp: 2026-04-11T10:13:33Z Generation: 1 Resource Version: 5932 UID: f7ffacc6-734a-4f28-bdc2-595db80a2a63 Spec: Common Name: test.example.com Dns Names: test.example.com www.test.example.com Duration: 2160h Issuer Ref: Kind: Issuer Name: selfsigned-issuer Renew Before: 360h Secret Name: test-cert-tls Subject: Organizations: Example Corp Status: Conditions: Last Transition Time: 2026-04-11T10:13:33Z Message: Certificate is up to date and has not expired Observed Generation: 1 Reason: Ready Status: True Type: Ready Not After: 2026-07-10T10:13:33Z Not Before: 2026-04-11T10:13:33Z Renewal Time: 2026-06-25T10:13:33Z Revision: 1 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Issuing 65s cert-manager-certificates-trigger Issuing certificate as Secret does not exist Normal Generated 65s cert-manager-certificates-key-manager Stored new private key in temporary Secret resource "test-cert-ktrpn" Normal Requested 65s cert-manager-certificates-request-manager Created new CertificateRequest resource "test-cert-1" Normal Issuing 65s cert-manager-certificates-issuing The certificate has been successfully issued ``` Key fields to inspect when diagnosing operator behavior | Field | What it tells you | | - | - | | `Type` (e.g., `Ready`) | The condition type the operator is reporting. | | `Status` (True/False) | Whether that condition is satisfied. | | `Message` | Human-readable explanation of the condition state. | | `Observed Generation` | Which spec generation the operator has observed. | | `Events` | Step-by-step reconciliation notes and reasons for failures or success. | Next, inspect the Secret that the operator created to hold the issued certificate: ```bash theme={null} $ kubectl get secret -n operator-lab NAME TYPE DATA AGE test-cert-tls kubernetes.io/tls 3 113s $ kubectl describe secret test-cert-tls -n operator-lab Name: test-cert-tls Namespace: operator-lab Labels: Annotations: Type: kubernetes.io/tls Data ==== ca.crt: 1065 bytes tls.crt: 2048 bytes tls.key: 1675 bytes ``` You can see the Secret contains `ca.crt`, `tls.crt`, and `tls.key`. The operator created this Secret automatically as a side effect of reconciling the Certificate resource. Make the reconciliation loop tangible: delete the Secret and watch the operator restore it. ```bash theme={null} $ kubectl delete secret test-cert-tls -n operator-lab secret "test-cert-tls" deleted # Within a few seconds the operator will recreate it: $ kubectl get secret -n operator-lab NAME TYPE DATA AGE test-cert-tls kubernetes.io/tls 3 7s ``` Operators continuously watch relevant resources and restore owned resources when they detect drift. This reconciliation loop is fundamental to operators: you cannot accidentally break the desired state long-term because the operator will reconcile it back. Start troubleshooting operators by running `kubectl describe` on the custom resource and reading the Conditions and Events. Conditions typically indicate Ready/NotReady states (`True`/`False`), and Events provide the reconciliation steps and reasons for failures or successes. Summary — key things to remember * Use `kubectl get` and `kubectl describe` on custom resources to inspect Status, Conditions, and Events. * Condition `Type` + `Status` + `Message` are your first diagnostic signals. * Operators continuously reconcile resources and will recreate owned resources if deleted. * The controller/operator enforces ownership and cleanup order intentionally; unexpected delete-order behavior is usually by design, not a bug. Links and references * cert-manager: [https://cert-manager.io/](https://cert-manager.io/) * Kubernetes documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/) * Helpful guide: [Kubernetes Operators — Concepts and Best Practices](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) > **[Watch Video](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/756ffaae-767b-4743-9724-c05d3fbf9a18/lesson/33c8c726-73a9-4e4f-9b19-f426aa8cc191)** > **[Practice Lab](https://learn.kodekloud.com/user/courses/prep-course-certified-cloud-native-platform-engineer-cnpe/module/756ffaae-767b-4743-9724-c05d3fbf9a18/lesson/208267db-ac21-46da-a59d-a686feee49f7)** This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.