Demo Reading Operator Status and Conditions

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:

$ kubectl describe issuer selfsigned-issuer -n operator-lab
Name:                selfsigned-issuer
Namespace:           operator-lab
Labels:              <none>
Annotations:         <none>
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:                <none>

Apply a Certificate resource. Example test-certificate.yaml:

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:

$ 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:

$ kubectl describe certificate test-cert -n operator-lab
Name:         test-cert
Namespace:    operator-lab
Labels:       <none>
Annotations:  <none>
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:

$ 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:       <none>
Annotations:  <none>
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.

$ 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/
Kubernetes documentation: https://kubernetes.io/docs/
Helpful guide: Kubernetes Operators — Concepts and Best Practices

Course Introduction

Platform Architecture and Infrastructure

GitOps and Continuous Delivery

Platform APIs and Self-Service Capabilities

Observability and Operations

Security and Policy Enforcement

Conclusion

Demo Reading Operator Status and Conditions

Watch Video

Practice Lab