From 3d5ca2d7ffd6f6fd0b2e6ab15c77d6184a4aec3f Mon Sep 17 00:00:00 2001 From: Tyler Kellen Date: Mon, 13 Nov 2017 22:10:24 -0500 Subject: [PATCH] re-order sections (#6241) For new readers without a detailed understanding of how deletion occurs, specifying foreground deletion first gives the needed context to understand what background deletion is eschewing. --- .../workloads/controllers/garbage-collection.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/concepts/workloads/controllers/garbage-collection.md b/docs/concepts/workloads/controllers/garbage-collection.md index f773c6bf02..b220a17cdd 100644 --- a/docs/concepts/workloads/controllers/garbage-collection.md +++ b/docs/concepts/workloads/controllers/garbage-collection.md @@ -70,12 +70,6 @@ deletion*. There are two modes of *cascading deletion*: *background* and *foreg If you delete an object without deleting its dependents automatically, the dependents are said to be *orphaned*. -### Background cascading deletion - -In *background cascading deletion*, Kubernetes deletes the owner object -immediately and the garbage collector then deletes the dependents in -the background. - ### Foreground cascading deletion In *foreground cascading deletion*, the root object first @@ -100,6 +94,12 @@ unauthorized dependents cannot delay deletion of an owner object. If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet), blockOwnerDeletion is set automatically and you do not need to manually modify this field. +### Background cascading deletion + +In *background cascading deletion*, Kubernetes deletes the owner object +immediately and the garbage collector then deletes the dependents in +the background. + ### Setting the cascading deletion policy To control the cascading deletion policy, set the `deleteOptions.propagationPolicy`