whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

address comments

Browse Source
This commit is contained in:
Chao Xu
2017-03-17 17:42:04 -07:00
parent 2626c980f9
commit 20fb544429
1 changed files with 14 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/concepts/workloads/controllers/garbage-collection.md
+14 -5
View File
@@ -28,8 +28,8 @@ points to the owning object.
Sometimes, Kubernetes sets the value of `ownerReference` automatically. For Sometimes, Kubernetes sets the value of `ownerReference` automatically. For
example, when you create a ReplicaSet, Kubernetes automatically sets the example, when you create a ReplicaSet, Kubernetes automatically sets the
`ownerReference` field of each Pod in the ReplicaSet. In 1.6, Kubernetes `ownerReference` field of each Pod in the ReplicaSet. In 1.6, Kubernetes
automatically sets the value of `ownerReference` for objects created by automatically sets the value of `ownerReference` for objects created or adopted
ReplicationController, Replicaset, StatefulSet, DaemonSet, and Deployment. by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and Deployment.
You can also specify relationships between owners and dependents by manually You can also specify relationships between owners and dependents by manually
setting the `ownerReference` field. setting the `ownerReference` field.
@@ -76,15 +76,24 @@ deletion*, the object first enters a "deletion in progress" state, where the
object is still visible via the REST API, its `deletionTimestamp` is set, and object is still visible via the REST API, its `deletionTimestamp` is set, and
its metadata.finalizers contains "foregroundDeletion". Then the garbage its metadata.finalizers contains "foregroundDeletion". Then the garbage
collector deletes the dependents. Once the garbage collector has deleted all collector deletes the dependents. Once the garbage collector has deleted all
dependents whose ownerReferences.blockOwnerDeletion=true, it will finally delete dependents whose ownerReference.blockOwnerDeletion=true, it will finally delete
the object. the object.
Note that in the "foregroundDeletion", only dependents with
ownerReference.blockOwnerDeletion block the deletion of the owner object. In
1.7, we will add an admission controller that disallows a user without the delete
permission of the owner object to set blockOwnerDeletion to true, so that such a
user cannot delay the deletion of the owner. For ownerReferences set up
by a controller, blockOwnerDeletion is set to true. So in most use cases, users
do not need to manually modify this field.
To control whether delete dependent objects or delete them in To control whether delete dependent objects or delete them in
foreground/background, set the deleteOptions.propagationPolicy to "Orphan", foreground/background, set the deleteOptions.propagationPolicy to "Orphan",
"Foregound", or "Background" respectively. "Foregound", or "Background" respectively.
The default garbage collection policy for controller resources is `orphan`. So unless you specify The default garbage collection policy for many controller resources is `orphan`,
otherwise, dependent objects are orphaned. including ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
Deployment. So unless you specify otherwise, dependent objects are orphaned.
Here's an example that deletes dependents in background: Here's an example that deletes dependents in background: