concepts/workloads/controllers/garbage-collection/

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. kubernetes垃圾收集器的作用是删除某些曾经拥有所有者但不再拥有所有者的对象。

• Owners and dependents
• Controlling how the garbage collector deletes dependents
• Known issues
• What's next

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 a metadata.ownerReferences field that points to the owning object. 一些kubernetes对象是其他对象的所有者。例如，复制集是一组pod的所有者。拥有的对象称为所有者对象的从属对象。每个依赖对象都有指向所属对象的“metadata.ownerreferences”字段。

Sometimes, Kubernetes sets the value of ownerReference automatically. For example, when you create a ReplicaSet, Kubernetes automatically sets the ownerReference field of each Pod in the ReplicaSet. In 1.8, Kubernetes automatically sets the value of ownerReference for objects created or adopted by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job and CronJob. 有时，kubernetes会自动设置“ownerreference”的值。例如，创建复制集时，kubernetes会自动设置复制集中每个pod的“ownerreference”字段。在1.8中，kubernetes自动为replicationcontroller、replicaset、statefulset、守护程序、部署、作业和cronjob创建或采用的对象设置“ownerreference”值。

You can also specify relationships between owners and dependents by manually setting the ownerReference field. 还可以通过手动设置“ownerreference”字段来指定所有者和从属对象之间的关系。

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

controllers/replicaset.yaml

apiVersion: apps/v1
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 metadata, you can see OwnerReferences field: 如果创建复制集，然后查看pod元数据，则可以看到ownerreferences字段：

kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
kubectl get pods --output=yaml

The output shows that the Pod owner is a ReplicaSet named 输出显示pod所有者是名为 my-repset:

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

Note: Cross-namespace owner references are disallowed by design. This means: 1) Namespace-scoped dependents can only specify owners in the same namespace, and owners that are cluster-scoped. 2) Cluster-scoped dependents can only specify cluster-scoped owners, but not namespace-scoped owners. 设计不允许跨命名空间所有者引用。这意味着：1）命名空间范围的从属项只能指定同一命名空间中的所有者，以及群集范围的所有者。2）群集范围的从属项只能指定群集范围的所有者，而不能指定命名空间范围的所有者。

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 called cascading deletion. There are two modes of cascading deletion: background and foreground. 删除对象时，可以指定是否也自动删除该对象的从属对象。自动删除从属项称为级联删除。有两种级联删除模式：后台和前台。

If you delete an object without deleting its dependents automatically, the dependents are said to be orphaned. 如果在不自动删除其从属对象的情况下删除对象，则这些从属对象称为孤立。

Foreground cascading deletion

In foreground 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 对象仍然通过rest api可见
• The object’s deletionTimestamp is set 对象的“deletitiontimestamp”已设置
• The object’s metadata.finalizers contains the value “foregroundDeletion”. 对象的“metadata.finalizers”包含值“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 with ownerReference.blockOwnerDeletion=true), it deletes the owner object. 一旦设置了“正在删除”状态，垃圾收集器将删除对象的从属对象。一旦垃圾收集器删除了所有“blocking”依赖项（具有“ownerreference.blockownerdelection=true”的对象），它就会删除owner对象。

Note that in the “foregroundDeletion”, only dependents with ownerReference.blockOwnerDeletion=true block the deletion of the owner object. Kubernetes version 1.7 added an admission controller that controls user access to set blockOwnerDeletion to true based on delete permissions on the owner object, so that unauthorized dependents cannot delay deletion of an owner object. 请注意，在“foregrounddeletion”中，只有具有“ownerreference.block owner deletion=true”的依赖项才能阻止所有者对象的删除。Kubernetes版本1.7添加了一个[许可控制器]（https://kubernetes.io/docs/reference/acces... authn authz/accessment controllers/ownerreferencesppermissionenforcement），用于控制用户访问，使其基于所有者对象上的删除权限将“blockownerdelement”设置为true，以便未经授权的从属对象不能延迟所有者的删除。反对。

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. 如果对象的“ownerreferences”字段由控制器设置（如部署或复制集），则会自动设置blockownerrelection，您无需手动修改此字段。

Background cascading deletion

In background cascading deletion, Kubernetes deletes the owner object immediately and the garbage collector then deletes the dependents in the background. 如果对象的“ownerreferences”字段由控制器设置（如部署或复制集），则会自动设置blockownerrelection，您无需手动修改此字段。

Setting the cascading deletion policy

To control the cascading deletion policy, set the propagationPolicy field on the deleteOptions argument when deleting an Object. Possible values include “Orphan”, “Foreground”, or “Background”. 若要控制级联删除策略，请在删除对象时在“deleteoptions”参数上设置“propagationpolicy”字段。可能的值包括“孤立”、“前景”或“背景”。

Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was orphan. 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. 在kubernetes 1.9之前，许多控制器资源的默认垃圾收集策略是“孤儿”。这包括replicationcontroller、replicaset、statefulset、守护进程和部署。对于“extensions/v1beta1”、“apps/v1beta1”和“apps/v1beta2”组版本中的类型，除非另有指定，否则默认情况下从属对象是孤立的。在kubernetes 1.9中，对于“apps/v1”组版本中的所有类型，默认情况下都会删除依赖对象。

Here’s an example that deletes dependents in background:

kubectl proxy --port=8080
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/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/apps/v1/namespaces/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/apps/v1/namespaces/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 --cascade to true. To orphan dependents, set --cascade to false. The default value for --cascade is true. kubectl还支持级联删除。要使用kubectl自动删除依赖项，请将“--cascade”设置为true。若要孤立依赖项，请将“--cascade”设置为false。“--cascade”的默认值为true。

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

kubectl delete replicaset my-repset --cascade=false

Additional note on Deployments

Prior to 1.7, When using cascading deletes with Deployments you must use propagationPolicy: Foreground to 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. See kubeadm/#149 for more information. 在1.7之前的版本中，对部署使用级联删除时，必须使用'propagationpolicy:foreground'不仅删除创建的复制集，还删除它们的pod。如果不使用这种类型的propagationpolicy，则只删除复制集，pods将成为孤立的。更多信息，请参见[kubeadm/149](https://github.com/kubernetes/kubeadm/issu... issuecomment-284766613)。

Known issues

Tracked at #26120

What's next

Design Doc 1

Design Doc 2

Feedback

Was this page helpful?

本作品采用《CC 协议》，转载必须注明作者和本文链接