Operators manage systems on behalf of custom resources (CRs). The managed state of the system should always be reflected in the CRs status sub resource to make these information available for consumption. The recommended pattern here is to have one operatorkit resource implementation to manage the system and one operatorkit resource implementation to provide the system's state in the CRs status sub resource. In the linked example we have the chart resource and the chartstatus resource. The advantage of this pattern is to have dedicated operatorkit resource implementations which can reconcile independently. That way different resync periods can be used for each operatorkit resource implementation.

All this is not black and white though. Best practises with the status management will also evolve further. One aspect which always has to be considered here is who reads and writes status and in which combination does this occur to be relevant or dramatically different than in other projects. As a guideline the approach of the separated resources should be considered the default for now because it keeps different responsibilities separated not mixed them up.

A common design guideline of an operator architecture is the delegation and propagation principle. The visualization below depicts how desired state is delegated and current state is propagated.