You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/book/src/reference/api/owner-references.md
+12-17
Original file line number
Diff line number
Diff line change
@@ -1,28 +1,29 @@
1
1
# Owner References
2
2
3
-
4
-
Cluster API uses [Kubernetes owner references](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) 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`.
3
+
Cluster API uses [Kubernetes owner references](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/) to track relationships between objects. These references are used
4
+
for Kubernetes garbage collection, which is also used for Cluster deletion in CAPI. They are also used places where
5
+
the ownership hierarchy is important, for example when using `clusterctl move`.
5
6
6
7
CAPI uses owner references in an opinionated way. The following guidelines should be considered:
7
-
1. 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.
8
-
2. 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.
8
+
1. Objects should always be created with an owner reference to prevent leaking objects. Initial ownerReferences can be
9
+
replaced later where another object is a more appropriate owner.
10
+
2. Owner references should be re-reconciled if they are lost for an object. This is required as some tools - e.g. velero -
11
+
may delete owner references on objects.
9
12
3. Owner references should be kept to the most recent apiVersion.
10
13
- This ensures garbage collection still works after an old apiVersion is no longer served.
11
14
4. Owner references should not be added unless required.
12
15
- Multiple owner references on a single object should be exceptional.
13
16
14
-
15
-
16
-
17
17
## Owner reference relationships in Cluster API
18
18
19
-
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.
20
-
19
+
The below tables map out the a reference for ownership relationships for the objects in a Cluster API cluster. The tables
20
+
are identical for classy and non-classy clusters.
21
21
22
22
Providers may implement their own ownership relationships which may or may not map directly to the below tables.
23
-
These owner references are almost all tested in an [end-to-end test](https://github.com/kubernetes-sigs/cluster-api/blob/caaa74482b51fae777334cd7a29595da1c06481e/test/e2e/quick_start_test.go#L31). 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.
23
+
These owner references are almost all tested in an [end-to-end test](https://github.com/kubernetes-sigs/cluster-api/blob/caaa74482b51fae777334cd7a29595da1c06481e/test/e2e/quick_start_test.go#L31). Lack of testing is noted where this is not the case.
24
+
CAPI Providers can take advantage of the e2e test framework to ensure their owner references are predictable, documented and stable.
0 commit comments