Lab: Owners and Garbage
Who deletes the children?.
When you delete a deployment, its replica sets and pods disappear, too. Nobody told them to. How does Kubernetes know? The answer is ownership. Every object records who owns it, and a garbage collector removes the orphans. In this lab, we read the ownership, and even break it, on purpose.

- Objects record their owner
- A garbage collector cleans up
- We can orphan children on purpose
Reading ownership
We create a deployment with two replicas. Now we ask for the pods, and their owner. Each pod says, I am owned by a replica set, with its name. Ask the replica set, and it would say, I am owned by the deployment. This chain is stored in a field called owner references. When the owner is deleted, the garbage collector notices, and deletes everything that pointed to it. That is why a single delete removes the whole tree.
kubectl create deployment own --image=nginx:1.27 --replicas=2 deployment.apps/own created kubectl get pods -l app=own -o custom-columns='POD:.metadata.name,OWNER:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name' POD OWNER OWNER_NAME own-67b96cc474-c9hnr ReplicaSet own-67b96cc474 own-67b96cc474-xf9dt ReplicaSet own-67b96cc474 kubectl get rs -l app=own -o custom-columns='RS:.metadata.name,OWNER:.metadata.ownerReferences[0].kind' RS OWNER own-67b96cc474 Deployment
Orphaning on purpose
Now the experiment. We delete the deployment, but with the cascade flag set to orphan. This tells Kubernetes, remove the owner, but leave the children alone. The deployment is gone, yet the two pods are still there, and so is the replica set, now with no owner. They keep running, because the replica set is still working. This is a handy trick, when you want to replace a controller, without restarting your pods. Of course, nobody manages them now, so we clean them up by hand.
kubectl delete deployment own --cascade=orphan deployment.apps "own" deleted from default namespace kubectl get pods -l app=own --no-headers | wc -l 2 kubectl get rs -l app=own -o name replicaset.apps/own-67b96cc474 kubectl delete rs,pods -l app=own --now replicaset.apps "own-67b96cc474" deleted from default namespace pod "own-67b96cc474-c9hnr" deleted from default namespace pod "own-67b96cc474-xf9dt" deleted from default namespace
Foreground, background, orphan
There are three ways to delete an owner. Background, the default, deletes the owner immediately, and the garbage collector removes the children afterwards. Foreground deletes the children first, and the owner disappears last, which is useful when you need to wait for everything to be gone. And orphan leaves the children behind. Knowing the three helps when scripts must wait for cleanup, or when you migrate controllers, without any downtime.
Cascade modes
- Background: owner first, children later
- Foreground: children first, owner last
- Orphan: children are left alone
When to use
- The everyday default
- When you must wait for full cleanup
- When replacing a controller safely
Summary
Excellent. Objects record owners, and the garbage collector deletes children, when the owner goes. Background, foreground, and orphan cascades control the order. Next, how Kubernetes tracks who changed what, with diff, and server side apply.
Key takeaways- ownerReferences link children to owners
- Garbage collector removes orphans
- --cascade=orphan keeps the children