AI Hints
Home›Kubernetes Tutorial›Bonus Labs: Under the Hood
Kubernetes · Lesson 79 of 86

Lab: Owners and Garbage

Who deletes the children?.

⏱ 2 min read▶ Video at 2:57:32🎓 Free
Watch this lesson in the Kubernetes courseWatch on YouTube ↗Full Kubernetes course

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.

Lab: Owners and Garbage
From the video: Lab: Owners and Garbage
  • 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
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
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
Next up: Lab: Diff and Server-Side Apply — who changed what?