kubernetes garbage collection

Garbage Collection

Role Kubernetes garbage collector is to delete the specified objects that once had but will no longer have the Owner.

Note: Garbage collection is a beta feature, enabled by default in Kubernetes 1.4 and above.

Owner 和 Dependent

Some Kubernetes objects are some other Owner. For example, a ReplicaSet Pod is a group of Owner. Owner object has been called the Owner  Dependent . Dependent Each object has a pointer to the object to which it belongs  metadata.ownerReferences field.

Sometimes, Kubernetes automatically set  ownerReference value. For example, when creating a ReplicaSet, Kubernetes ReplicaSet automatic setting of each Pod  ownerReference field value. In version 1.6, Kubernetes some objects will automatically set the  ownerReference value of these objects are created or managed by ReplicationController, ReplicaSet, StatefulSet, DaemonSet and Deployment.

You may be manually set  ownerReference value, to specify the relationship between the Owner and Dependent.

This has a profile represents a Pod th ReplicaSet 3 having:

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata: name: my-repset spec: replicas: 3 selector: matchLabels: pod-is-for: garbage-collection-example template: metadata: labels: pod-is-for: garbage-collection-example spec: containers: - name: nginx image: nginx

 

If you create the ReplicaSet, and then view the Pod's metadata fields, you can see OwnerReferences fields:

kubectl create -f https://k8s.io/docs/concepts/abstractions/controllers/my-repset.yaml
kubectl get pods --output=yaml

 

Owner output shows the Pod is called my-repset ReplicaSet of:

apiVersion: v1
kind: Pod
metadata: ... ownerReferences: - apiVersion: extensions/v1beta1 controller: true blockOwnerDeletion: true kind: ReplicaSet name: my-repset uid: d9607e19-f88f-11e6-a518-42010a800195 ...

 

Control the garbage collector to delete Dependent

When you delete an object, you can specify whether the object Dependent automatically deleted. Dependent automatically deleted also known as  cascading deletes . Kubernetes There are two  cascading deletes  modes: background  mode and  foreground  mode.

If you delete an object, it does not automatically delete the Dependent, Dependent these are called the original target of  orphans .

Background cascade delete

In the  background cascade delete  mode, Kubernetes Owner object is deleted immediately, then the garbage collector will remove these Dependent in the background.

Foreground cascade delete

In the  foreground cascade delete  mode, the root object is first to enter the "delete" status. In the case of "delete" status will be as follows:

• Objects can still be seen through the REST API
• Targets will  deletionTimestamp field
• Object  metadata.finalizers field contains the value "foregroundDeletion"

Once set to "delete" status, the garbage collector will remove all objects Dependent. Garbage collector to delete all the "Blocking" of Dependent (object  ownerReference.blockOwnerDeletion=trueafter), it will delete the Owner object.

Note that in the "foreground delete" mode, Dependent only through  ownerReference.blockOwnerDeletion in order to prevent the removal Owner object. Increase admission controller in the Kubernetes 1.7 version, to control the user to set the delete permissions based on the Owner object  blockOwnerDeletion is true, so unauthorized Dependent can not be delayed deletion Owner object.

If an object ownerReferences field is a Controller (e.g. Deployment or ReplicaSet) setting blockOwnerDeletion is automatically set, not necessary to manually modify this field.

Setting the Cascading deletion policy

Owner object by setting  deleteOptions.propagationPolicy the fields, you can delete cascade control strategy. Possible values include: "orphan", "Foreground" or "Background".

Controller of many resources, including ReplicationController, ReplicaSet, StatefulSet, DaemonSet and Deployment, default garbage collection strategy  orphan. Therefore, unless you specify other garbage collection strategies, otherwise all Dependent objects are used  orphan strategy.

Note: The default value of this paragraph refers to the default value defaults REST API, not kubectl command, kubectl default cascading deletes, will be mentioned later.

Here is a deletion Dependent objects in the background example:

kubectl proxy --port=8080
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"

 

Here is a deletion Dependent object in the foreground examples:

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 is an example of an orphan Dependent:

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 deletes. By setting  --cascade to true, you can use kubectl automatically deleted Dependent objects. Is set  --cascade to false, the object will Dependent Dependent orphaned objects. --cascade The default value is true.

The following is an example of the object ReplicaSet Dependent Dependent of orphaned:

kubectl delete replicaset my-repset --cascade=false

 

Known issues

• Version 1.7, the garbage collector does not support  custom resource , such as those by CustomResourceDefinition new, or gathered together by the API server resource object.