Cluster API uses Kubernetes owner references to track relationships between objects. These references are used for Kubernetes garbage collection, which is the basis of Cluster deletion in CAPI. They are also used places where the ownership hierarchy is important, for example when using clusterctl move.
CAPI uses owner references in an opinionated way. The following guidelines should be considered:
Objects should always be created with an owner reference to prevent leaking objects. Initial ownerReferences can be replaced later where another object is a more appropriate owner.
Owner references should be re-reconciled if they are lost for an object. This is required as some tools - e.g. velero - may delete owner references on objects.
Owner references should be kept to the most recent apiVersion.
This ensures garbage collection still works after an old apiVersion is no longer served.
Owner references should not be added unless required.
Multiple owner references on a single object should be exceptional.
The below tables map out the a reference for ownership relationships for the objects in a Cluster API cluster. The tables are identical for classy and non-classy clusters.
Providers may implement their own ownership relationships which may or may not map directly to the below tables.
These owner references are almost all tested in an end-to-end test. Lack of testing is noted where this is not the case. CAPI Providers can take advantage of the e2e test framework to ensure their owner references are predictable, documented and stable.