update gc doc for foreground garbage collection; add known issues for

non-core resources
This commit is contained in:
Chao Xu
2017-03-16 17:37:26 -07:00
parent 9886f27a2e
commit 2626c980f9
@@ -27,9 +27,12 @@ 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. You can also specify `ownerReference` field of each Pod in the ReplicaSet. In 1.6, Kubernetes
relationships between owners and dependents by manually setting the automatically sets the value of `ownerReference` for objects created by
`ownerReference` field. ReplicationController, Replicaset, StatefulSet, DaemonSet, and Deployment.
You can also specify relationships between owners and dependents by manually
setting the `ownerReference` field.
Here's a configuration file for a ReplicaSet that has three Pods: Here's a configuration file for a ReplicaSet that has three Pods:
@@ -53,38 +56,67 @@ metadata:
ownerReferences: ownerReferences:
- apiVersion: extensions/v1beta1 - apiVersion: extensions/v1beta1
controller: true controller: true
blockOwnerDeletion: true
kind: ReplicaSet kind: ReplicaSet
name: my-repset name: my-repset
uid: d9607e19-f88f-11e6-a518-42010a800195 uid: d9607e19-f88f-11e6-a518-42010a800195
... ...
``` ```
## Controlling whether the garbage collector deletes dependents ## Controlling whether and how the garbage collector deletes dependents
When you delete object, you can specify whether the object's dependents When you delete object, you can specify whether the object's dependents are
are deleted automatically. Deleting dependents automatically is called deleted automatically. If you delete an object without deleting its dependents
*cascading deletion*. If you delete an object without deleting its automatically, the dependents are said to be *orphaned*. Deleting dependents
dependents automatically, the dependents are said to be *orphaned*. automatically is called *cascading deletion*. Further, there are two modes of
*cascading deletion*: if the object is deleted immediately and the garbage
collector then deletes the dependents in the background, it is called
*background cascading deletion*. In contrast, in *foreground cascading
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
its metadata.finalizers contains "foregroundDeletion". Then the garbage
collector deletes the dependents. Once the garbage collector has deleted all
dependents whose ownerReferences.blockOwnerDeletion=true, it will finally delete
the object.
To delete dependent objects automatically, set the `orphanDependents` query To control whether delete dependent objects or delete them in
parameter to false in your request to delete the owner object. foreground/background, set the deleteOptions.propagationPolicy to "Orphan",
"Foregound", or "Background" respectively.
To orphan the dependents of an owner object, set the `orphanDependents` query The default garbage collection policy for controller resources is `orphan`. So unless you specify
parameter to true in your request to delete the owner object.
The default value for `orphanDependents` is true. So unless you specify
otherwise, dependent objects are orphaned. otherwise, dependent objects are orphaned.
Here's an example that deletes dependents automatically: Here's an example that deletes dependents in background:
```shell ```shell
kubectl proxy --port=8080 kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset?orphanDependents=false curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
-H "Content-Type: application/json"
``` ```
To delete dependents automatically using kubectl, set `--cascade` to true. Here's an example that deletes dependents in foreground:
To orphan dependents, set `--cascade` to false. The default value for
`--cascade` is true. ```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
-H "Content-Type: application/json"
```
Here's an example that orphans dependents:
```shell
kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/my-repset \
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
-H "Content-Type: application/json"
```
kubectl also supports cascading deletion, though implemented in a different way.
To delete dependents automatically using kubectl, set `--cascade` to true. To
orphan dependents, set `--cascade` to false. The default value for `--cascade`
is true.
Here's an example that orphans the dependents of a ReplicaSet: Here's an example that orphans the dependents of a ReplicaSet:
@@ -92,20 +124,23 @@ Here's an example that orphans the dependents of a ReplicaSet:
kubectl delete replicaset my-repset --cascade=false kubectl delete replicaset my-repset --cascade=false
``` ```
## Ongoing development ## Known issues
* In 1.6, garbage collection does not support non-core resources, e.g.,
resources added via ThirdPartyResource or via aggregated API servers. It will
support non-core resources in the future. When it does, garbage collector will
delete objects with ownerRefereneces referring to non-existent object of a
valid non-core resource.
In Kubernetes version 1.5, synchronous garbage collection is under active [Other known issues](https://github.com/kubernetes/kubernetes/issues/26120)
development. See the tracking
[issue](https://github.com/kubernetes/kubernetes/issues/29891) for more details.
{% endcapture %} {% endcapture %}
{% capture whatsnext %} {% capture whatsnext %}
[Design Doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/garbage-collection.md) [Design Doc 1](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/garbage-collection.md)
[Known issues](https://github.com/kubernetes/kubernetes/issues/26120) [Design Doc 2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/synchronous-garbage-collection.md)
{% endcapture %} {% endcapture %}