Hey everyone! I've been working on an operator at work for a set of specific resources, and I've run into some confusion about what exactly should go into the Status field of my Custom Resource Definition (CRD). I know that .Spec describes the desired state and .Status reflects the current state, but I'm not entirely sure how to structure them.
I've created a dummy CRD example called CustomLB, which includes fields like Image, Port, and Scheme in both Spec and Status, along with a State field that indicates if it's Failed, Deployed, Paused, etc. My thought process was that if a user updates the Port from 8080 to 8081, the controller would update the underlying service and then update the Status field accordingly. However, I've noticed that in many existing Kubernetes resources, the Status fields don't always mirror the Spec fields. How do these controllers manage the desired and current states without having matching fields? Are conditions a better way to approach this? I'm starting to think I might not fully grasp the purpose of the Status field.
1 Answer
It seems like there's a bit of confusion here. The Status field is mainly used by the controller to indicate its position in the reconciliation process. Sometimes it can be purely informational or necessary for storing state that can’t be derived externally. In your case, since your controller promptly updates the downstream resources with the new port value, there's really no need for an intermediate status here. So, you might consider leaving the Status field empty.
Got it! That makes sense. So, if I understand correctly, I only need to include fields like Port or Scheme in Status if another controller needs to access the current value rather than the desired one in Spec?