<p>I am using kubebuilder to create a Kubernetes operator. When an object of my kind is initiated I have to parse the spec and update the objects based on a few calculations. </p>

<p>From what I can tell I can either update the status of the object, the metadata, or a managed field (I may be wrong?). It appears that the <code>sigs.k8s.io/controller-runtime/pkg/client</code> library is responsible for how to update these fields (I'm not completely sure). I am having trouble understanding the <a href="https://godoc.org/sigs.k8s.io/controller-runtime/pkg/client#Patch" rel="nofollow noreferrer">docs</a>. </p>

<p>I have the following questions:</p>

<ul>
<li>Are there a guide to best practices about where to store configuration on the object between status, metadata (labels or annotations), and managed fields?</li>
<li>How do I update/patch the annotations of an object similar to how I would use <code>r.Status().Update(ctx, &amp;thing);</code> to update the status?</li>
</ul>

<p>The <a href="https://book.kubebuilder.io/" rel="nofollow noreferrer">Kubebuilder docs</a> are a bit raw but nonetheless are a handy guide when building CRDs and controllers with Kubebuilder. It walks you through a fairly detailed example which is great to study and refer back to, to see how to do certain things.</p>

<p>The answer to your question generally is, "it depends." What values are you calculating, and why? Why do you need to store them on the object? Is the lifecycle of this data coupled to the lifecycle of this object, or might this computed data need to live on and be used by other controllers even when the object is deleted? In general, is anything going to interact with those values? What is it going to do with them?</p>

<p>If nothing else aside from the reconciliation controller for the CRD is going to interact with the data you're putting, consider putting it within the object's Status.</p>

<p>Doing <code>r.Status().Update(ctx, &amp;thing)</code> will avoid triggering any side-effects as it will only persist changes you've made to the object's Status subresource, rather than its spec or metadata.</p>

<p>A common thing to do with custom resources is to set and remove finalizers, which live in the object's metadata.</p>
