How is garbage collection and cascading deletion implemented?

tl;dr how does apiserver maintain mapping of parent:child objects, it appears it only has child:parent mapping.

Reading Garbage Collection docs and the biggest question in my mind is that how’s the garbage collection or features like blockOwnerDeletion efficiently implemented?

To illustrate it better: Imagine there are hundreds of thousands of individual objects of different kinds in a namespace, and any one of them can list a particular object in the ownerReferences. In this situation, when an “owner” object is deleted, how does the apiserver find what are its children?

There’s a reference from the child object to its parent, but not vice versa. So how does the api find an object’s children during cascading deletion without exhaustively searching all objects? Or when a parent object is being deleted, how does apiserver enforce constraints like blockOwnerDeletion that was listed on a child object without doing similar exhaustive searching?

@KarlKFI has answered this on this twitter thread.

The dependency graph is built by maintaining an informer on all resources since (parent → child mapping doesn’t exist on the API objects). Therefore, it’s not really all that efficient if you have a lot of relationships and a lot of objects on the API.

The code is here: kubernetes/graph_builder.go at v1.25.2 · kubernetes/kubernetes · GitHub

1 Like