Sign In

Curriculum 9: Deleting Resources

Cascading Deletes

10 min · 15 XP

Cascading Deletes

When you delete a Deployment, what happens to its ReplicaSets and Pods? That depends on the cascading deletion policy. Kubernetes offers three options that control whether and how child resources are cleaned up.

The Owner-Dependent Relationship

Kubernetes resources form ownership trees. A Deployment owns its ReplicaSets, and each ReplicaSet owns its Pods. When you delete an owner, the cascading policy determines what happens to its dependents.

Deployment (owner)
  └── ReplicaSet (dependent)
       └── Pod (dependent)
       └── Pod (dependent)

Foreground Cascading Deletion

In foreground deletion, the owner resource is not fully deleted until all its dependents are removed first. The process works like this:

  1. The owner is marked for deletion (it enters a "deletion in progress" state)
  2. The garbage collector deletes all dependents
  3. Once all dependents are gone, the owner is deleted
kubectl delete deployment my-app --cascade=foreground

Use foreground deletion when you need to ensure all Pods are stopped before the Deployment is removed.

Background Cascading Deletion (Default)

Background deletion is the default behavior. The owner is deleted immediately, and the garbage collector removes dependents asynchronously in the background:

# These are equivalent -- background is the default
kubectl delete deployment my-app
kubectl delete deployment my-app --cascade=background

The API server removes the Deployment right away, and you get your terminal back. Behind the scenes, the garbage collector cleans up the ReplicaSets and Pods.

Orphan Deletion

Orphan deletion removes the owner but leaves all dependents running. The dependents become "orphans" with no owner:

kubectl delete deployment my-app --cascade=orphan

After this command:

  • The Deployment is deleted
  • The ReplicaSet continues to exist
  • The Pods continue to run

This is useful when you want to replace a Deployment's configuration without disrupting the running Pods. You can then create a new Deployment that adopts the existing ReplicaSet.

Checking Owner References

You can see ownership relationships in the resource metadata:

# Check what owns a ReplicaSet
kubectl get replicaset my-app-7d4b8c6f5 -o jsonpath='{.metadata.ownerReferences[*].name}'

# Check what owns a Pod
kubectl get pod my-app-7d4b8c6f5-abc12 -o jsonpath='{.metadata.ownerReferences[*].kind}'

Key Takeaways

  • Foreground deletion waits for all dependents to be removed before deleting the owner
  • Background deletion (default) deletes the owner immediately and cleans up dependents later
  • Orphan deletion leaves dependents running when the owner is removed
  • Owner references define the parent-child relationships between resources
  • Choose the right cascading policy based on whether you need ordered cleanup