英文地址：https://kubernetes.io/docs/concepts/workloads/controllers/garbage-collection/

垃圾回收

The role of the Kubernetes garbage collector is to delete certain objects that once had an owner, but no longer have an owner.

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

Owners and dependents

Some Kubernetes objects are owners of other objects. For example, a ReplicaSet is the owner of a set of Pods. The owned objects are called_dependents_of the owner object. Every dependent object has ametadata.ownerReferencesfield that points to the owning object.

Sometimes, Kubernetes sets the value ofownerReferenceautomatically. For example, when you create a ReplicaSet, Kubernetes automatically sets theownerReferencefield of each Pod in the ReplicaSet. In 1.8, Kubernetes automatically sets the value ofownerReferencefor objects created or adopted by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job and CronJob.

You can also specify relationships between owners and dependents by manually setting theownerReferencefield.

Here’s a configuration file for a ReplicaSet that has three Pods:

`my-repset.yaml`
	apiVersion:extensions/v1beta1kind:ReplicaSetmetadata:name:my-repsetspec:replicas:3selector:matchLabels:pod-is-for:garbage-collection-exampletemplate:metadata:labels:pod-is-for:garbage-collection-examplespec:containers:-name:nginximage:nginx

If you create the ReplicaSet and then view the Pod metadata, you can see OwnerReferences field:

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

The output shows that the Pod owner is a ReplicaSet named my-repset:

apiVersion: v1
kind: Pod
metadata:
  ...
  ownerReferences:
  - apiVersion: extensions/v1beta1
    controller: 
true

blockOwnerDeletion: 
true

kind: ReplicaSet
    name: my-repset
    uid: d9607e19-f88f-11e6-a518-42010a800195
  ...

Controlling how the garbage collector deletes dependents

When you delete an object, you can specify whether the object’s dependents are also deleted automatically. Deleting dependents automatically is calledcascading deletion. There are two modes ofcascading deletion:background_and_foreground.

If you delete an object without deleting its dependents automatically, the dependents are said to beorphaned.

Foreground cascading deletion

Inforeground cascading deletion, the root object first enters a “deletion in progress” state. In the “deletion in progress” state, the following things are true:

The object is still visible via the REST API
The object’s deletionTimestamp is set
The object’s metadata.finalizers contains the value “foregroundDeletion”.

Once the “deletion in progress” state is set, the garbage collector deletes the object’s dependents. Once the garbage collector has deleted all “blocking” dependents (objects withownerReference.blockOwnerDeletion=true), it delete the owner object.

Note that in the “foregroundDeletion”, only dependents withownerReference.blockOwnerDeletionblock the deletion of the owner object. Kubernetes version 1.7 added anadmission controllerthat controls user access to setblockOwnerDeletionto true based on delete permissions on the owner object, so that unauthorized dependents cannot delay deletion of an owner object.

If an object’sownerReferencesfield 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

Inbackground 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 thepropagationPolicyfield on thedeleteOptionsargument when deleting an Object. Possible values include “Orphan”, “Foreground”, or “Background”.

Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources wasorphan. This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and Deployment. For kinds in the extensions/v1beta1, apps/v1beta1, and apps/v1beta2 group versions, unless you specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the apps/v1 group version, dependent objects are deleted by default.

Here’s an example that deletes dependents in background:

kubectl proxy 
--port
=
8080
curl 
-X
 DELETE localhost:8080/apis/extensions/v1beta1
amespaces/default/replicasets/my-repset 
\
-d
'{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}'
\
-H
"Content-Type: application/json"

Here’s an example that deletes dependents in foreground:

kubectl proxy 
--port
=
8080
curl 
-X
 DELETE localhost:8080/apis/extensions/v1beta1
amespaces/default/replicasets/my-repset 
\
-d
'{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}'
\
-H
"Content-Type: application/json"

Here’s an example that orphans dependents:

kubectl proxy 
--port
=
8080
curl 
-X
 DELETE localhost:8080/apis/extensions/v1beta1
amespaces/default/replicasets/my-repset 
\
-d
'{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}'
\
-H
"Content-Type: application/json"

kubectl also supports cascading deletion. To delete dependents automatically using kubectl, set--cascadeto true. To orphan dependents, set--cascadeto false. The default value for--cascadeis true.

Here’s an example that orphans the dependents of a ReplicaSet:

kubectl delete replicaset my-repset 
--cascade
=
false

Additional note on Deployments

When using cascading deletes with Deployments you_must_usepropagationPolicy: Foregroundto delete not only the ReplicaSets created, but also their Pods. If this type of_propagationPolicy_is not used, only the ReplicaSets will be deleted, and the Pods will be orphaned. Seekubeadm/#149for more information.

Garbage Collection