When exactly do I set an ownerReference's controller field to true?
According to the documentation:
Sometimes, Kubernetes sets the value of ownerReference automatically. For example, when you create a ReplicaSet, Kubernetes automatically sets the ownerReference field of each Pod in the ReplicaSet. In 1.6, Kubernetes automatically sets the value of ownerReference for objects created or adopted by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and Deployment.
You can also specify relationships between owners and dependents by manually setting the
ownerReference
field.
Basically, a Deployment is on the top of the ownership hierarchy, and ownerReference
is not set to it automatically. Therefore, you can manually add ownerReference
to your Deployment to create the reference to your Foo
resource.
You asked:
The follow on question here is of course: OK, what behavior changes if
controller
is set tofalse
here, but the otherownerReference
fields are set as above?
OwnerReference is used by a Garbage Collector. The role of the Kubernetes Garbage Collector is to delete certain objects that once had an owner, but no longer have it.
Here is the link to the description of the OwnerReference structure on Github. As you mentioned, if controller: true
, the reference points to the managing controller, in other words, the owner. And also, it is the instruction for Garbage Collector's behavior related to the object and its owner. If controller: false
, Garbage Collector manages the object as an object without an owner, for example, allows to delete it freely.
For more information, you can visit the following links:
- Garbage Collection
- Deletion and Garbage Collection of Kubernetes Objects
ownerReferences
has two purposes:
- Garbage collection: Refer to the answer of ymmt2005. Essentially all owners are considered for GC. Contrary to the accepted answer the
controller
field has no impact on GC. - Adoption: The
controller
field prevents fighting over resource which are to be adopted. Consider a replica set. Usually, the replica set controller creates the pods. However, if there is a pod which matches the label selector it will be adopted by the replica set. To prevent two replica sets fighting over the same pod, the latter is given a unique controller by setting thecontroller
totrue
. If a resource already has a controller it will not be adopted by another controller. Details are in the design proposal.
TLDR: The field controller
is only used for adoption and not GC.