Managing External State with Status Subresources

In this lesson, you will learn how to provide real-time operational transparency by decoupling your Custom Resource's desired configuration from its actual runtime state using the status subresource.

Why Separate Spec from Status?

In Kubernetes, we follow a declarative pattern: the spec defines what you want the cluster to look like, while the status describes what the cluster currently looks like. If you mix these, your controller might accidentally overwrite user-provided configuration while trying to report progress. By enabling the status subresource in your Custom Resource Definition (CRD), you create a protected field that only your controller should write to, while the user remains in control of the spec.

Implementing the Status Subresource

To use this, you must define the status field in your CRD manifest. When the controller runs its reconciliation logic, it should constantly evaluate the external state (e.g., checking if a database is reachable or an API is responding) and update the status field accordingly.

Here is how you might represent the state in your Go controller logic using the Client interface:

// After verifying external state, update the resource
myResource.Status.Phase = "Ready"
myResource.Status.ObservedGeneration = myResource.Generation
myResource.Status.LastUpdate = time.Now().Format(time.RFC3339)

err := r.Status().Update(ctx, myResource)
if err != nil {
    return ctrl.Result{}, err
}

The Benefits of This Pattern

Using the status subresource provides three major advantages:

1. Optimistic Locking: By using r.Status().Update(), Kubernetes uses the resource's resourceVersion to ensure you aren't overwriting changes made by another process.
2. User Feedback: Users can run kubectl get myresource -o yaml and immediately see if the operator has successfully provisioned the external infrastructure or if it is currently stuck in a "Pending" state.
3. Efficiency: It allows external monitoring tools to query the status without triggering the controller’s main reconciliation loop, keeping your operator performant.

Key Takeaway: Always use the status subresource to report the real-time health and progress of your operator, keeping operational feedback distinct from the user's desired configuration in the spec.