您正在查看 Kubernetes 版本的文档: v1.21

Kubernetes v1.21 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。

垃圾收集

Kubernetes 垃圾收集器的作用是删除某些曾经拥有属主(Owner)但现在不再拥有属主的对象。

属主和附属

某些 Kubernetes 对象是其它一些对象的属主。 例如,一个 ReplicaSet 是一组 Pod 的属主。 具有属主的对象被称为是属主的 附属 。 每个附属对象具有一个指向其所属对象的 metadata.ownerReferences 字段。

有时,Kubernetes 会自动设置 ownerReference 的值。 例如,当创建一个 ReplicaSet 时,Kubernetes 自动设置 ReplicaSet 中每个 Pod 的 ownerReference 字段值。 在 Kubernetes 1.8 版本,Kubernetes 会自动为某些对象设置 ownerReference 的值。 这些对象是由 ReplicationController、ReplicaSet、StatefulSet、DaemonSet、Deployment、 Job 和 CronJob 所创建或管理的。

你也可以通过手动设置 ownerReference 的值,来指定属主和附属之间的关系。

下面的配置文件中包含一个具有 3 个 Pod 的 ReplicaSet:

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

如果你创建该 ReplicaSet,然后查看 Pod 的 metadata 字段,能够看到 OwnerReferences 字段:

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

输出显示了 Pod 的属主是名为 my-repset 的 ReplicaSet:

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

根据设计,kubernetes 不允许跨名字空间指定属主。

名字空间范围的附属可以指定集群范围的或者名字空间范围的属主。

名字空间范围的属主必须和该附属处于相同的名字空间。 如果名字空间范围的属主和附属不在相同的名字空间,那么该属主引用就会被认为是缺失的, 并且当附属的所有属主引用都被确认不再存在之后,该附属就会被删除。

集群范围的附属只能指定集群范围的属主。 在 v1.20+ 版本,如果一个集群范围的附属指定了一个名字空间范围类型的属主, 那么该附属就会被认为是拥有一个不可解析的属主引用,并且它不能够被垃圾回收。

在 v1.20+ 版本,如果垃圾收集器检测到无效的跨名字空间的属主引用, 或者一个集群范围的附属指定了一个名字空间范围类型的属主, 那么它就会报告一个警告事件。该事件的原因是 OwnerRefInvalidNamespaceinvolvedObject 属性中包含无效的附属。你可以通过以下命令来获取该类型的事件:

kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace

控制垃圾收集器删除附属

当你删除对象时,可以指定该对象的附属是否也自动删除。 自动删除附属的行为也称为 级联删除(Cascading Deletion) 。 Kubernetes 中有两种 级联删除 模式:后台(Background) 模式和 前台(Foreground) 模式。

如果删除对象时,不自动删除它的附属,这些附属被称作 孤立对象(Orphaned)

前台级联删除

前台级联删除 模式下,根对象首先进入 deletion in progress 状态。 在 deletion in progress 状态,会有如下的情况:

  • 对象仍然可以通过 REST API 可见。
  • 对象的 deletionTimestamp 字段被设置。
  • 对象的 metadata.finalizers 字段包含值 foregroundDeletion

一旦对象被设置为 deletion in progress 状态,垃圾收集器会删除对象的所有附属。 垃圾收集器在删除了所有有阻塞能力的附属(对象的 ownerReference.blockOwnerDeletion=true) 之后,删除属主对象。

注意,在 foregroundDeletion 模式下,只有设置了 ownerReference.blockOwnerDeletion 值的附属才能阻止删除属主对象。 在 Kubernetes 1.7 版本增加了 准入控制器, 基于属主对象上的删除权限来控制用户设置 blockOwnerDeletion 的值为 True, 这样未经授权的附属不能够阻止属主对象的删除。

如果一个对象的 ownerReferences 字段被一个控制器(例如 Deployment 或 ReplicaSet)设置, blockOwnerDeletion 也会被自动设置,你不需要手动修改这个字段。

后台级联删除

后台级联删除 模式下,Kubernetes 会立即删除属主对象,之后垃圾收集器 会在后台删除其附属对象。

设置级联删除策略

通过为属主对象设置 deleteOptions.propagationPolicy 字段,可以控制级联删除策略。 可能的取值包括:OrphanForeground 或者 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"

下面是一个在前台中删除附属对象的示例:

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"

下面是一个令附属成为孤立对象的示例:

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 命令也支持级联删除。 通过设置 --cascade=foreground,可以使用 kubectl 在前台删除附属对象。 设置 --cascade=orphan,会使附属对象成为孤立附属对象。 当不指定 --cascade 或者明确地指定它的值为 background 的时候, 默认的行为是在后台删除附属对象。

下面是一个例子,使一个 ReplicaSet 的附属对象成为孤立附属:

kubectl delete replicaset my-repset --cascade=orphan

Deployment 的附加说明

在 1.7 之前的版本中,当在 Deployment 中使用级联删除时,你 必须使用 propagationPolicy:Foreground 模式以便在删除所创建的 ReplicaSet 的同时,还删除其 Pod。 如果不使用这种类型的 propagationPolicy,将只删除 ReplicaSet,而 Pod 被孤立。

有关信息请参考 kubeadm/#149

已知的问题

跟踪 #26120

接下来