设想这么一个场景:我们在 K8s 上创建了一个对象,它根据需要生成副本集和 Pod。在检查时,我们遗漏了容器某个属性的设置,因此又重新编辑了 Deployment。新的 Deployment 就产生了新的副本集对象和新的 Pod。这里就出现了一个问题,旧的副本集和 Pop 去哪了?另外,如果直接删除 Deployment,那副本集和 Pod 又会如何?事实就是,在删除 Deployment 后,副本集和 Pod 也会一起被删除,要不然集群早就乱套了。

在这个场景之下,我们可以深入思考几个问题:在 K8s 中该如何实现级联删除?有几种级联删除策略?在 K8s 中有没有可能存在孤儿对象(orphan object)这些问题其实就是典型的垃圾回收(garbage collection,GC)问题。本文将介绍 K8s 中垃圾回收的概念以及实现方法。

什么是垃圾回收?

一般来说,垃圾回收(GC)就是从系统中删除未使用的对象,并释放分配给它们的计算资源。GC 存在于所有的高级编程语言中,较低级的编程语言通过系统库实现 GC。
GC 最常见的算法之一是 mark-and-sweep,这个算法会标记将删除的对象,再进行删除,如下图所示:

OwnerRefernce

在面向对象的语言中,一些对象会引用其他对象或者直接由其他对象组成,k8s 也有类似形式,例如副本集管理一组 Pod,而 Deployment 又管理着副本集。

但与面向对象语言不同的是,在 K8s 对象的定义中,没有明确所有者之间的关系,那么系统要如何确定它们的关系呢?其实,在 K8s 中,每个从属对象都具有 唯一数据字段名称 metadata.ownerReferences 用于确定关系。从 Kubernetes v1.8 开始,K8s 对于 ReplicaSet、StatefulSet、DaemonSet、Deployment、Job、 CronJob 等创建或管理的对象,会自动为其设置 ownerReferences 的值。如果有需要,我们还可以手动设置 ownerReferences。以下内容显示了 core-dns Deployment 上 metadata.ownerReferences 的值。

k get deployment -n kube-system -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES
coredns 2/2 2 2 44d coredns k8s.gcr.io/coredns:1.6.7


k get rs -n kube-system -o json | jq ".items[0].metadata.name, .items[0].metadata.ownerReferences"
"coredns-66bff467f8"
[
{
"apiVersion": "apps/v1",
"blockOwnerDeletion": true,
"controller": true,
"kind": "Deployment",
"name": "coredns",
"uid": "d8f29b78-439c-497e-9a45-7c33bd626a9f"
}
]

k get pods coredns-66bff467f8-rsnmg -n kube-system -o json | jq ".metadata.name, .metadata.ownerReferences"
"coredns-66bff467f8-rsnmg"
[
{
"apiVersion": "apps/v1",
"blockOwnerDeletion": true,
"controller": true,
"kind": "ReplicaSet",
"name": "coredns-66bff467f8",
"uid": "085d5398-1358-43e2-918e-2e03da18c7bd"
}
]

认真观察上述命令的输出,其实它和其他对象 GC 之间是有些许差别的。对象关联参考金字塔是颠倒的:

K8s 的垃圾回收策略

如前面所讲,在 Kubernetes v1.8 之前,依赖对象逻辑删除的实现是在客户端,对于某些资源而言则是在控制器端。有时,客户端会中途失败,导致集群状态混乱,需要手动清理。后来为了解决这个问题,K8s 社区引入并实现了 Garbage Collector Controller(垃圾回收器),用更好用且更简单的方式实现 GC。在 K8s 中,有两大类 GC:

  • 级联(Cascading):在级联删除中,所有者被删除,那集群中的从属对象也会被删除。
  • 孤儿(Orphan):这种情况下,对所有者的进行删除只会将其从集群中删除,并使所有对象处于“孤儿”状态。

级联删除

在级联删除(cascading deletion strategy)中,从属对象(dependent object)与所有者对象(owner object)会被一起删除。在级联删除中,又有两种模式:前台(foreground)后台(background)

前台级联删除(Foreground Cascading Deletion):在这种删除策略中,所有者对象的删除将会持续到其所有从属对象都被删除为止。当所有者被删除时,会进入“正在删除”(deletion in progress)状态,此时:

  • 对象仍然可以通过 REST API 查询到(可通过 kubectl 或 kuboard 查询到)
  • 对象的 deletionTimestamp 字段被设置
  • 对象的 metadata.finalizers 包含值 foregroundDeletion

一旦对象被设置为 “正在删除” 状态,垃圾回收器将删除其从属对象。当垃圾回收器已经删除了所有的“blocking”从属对象(ownerReference.blockOwnerDeletion=true 的对象)以后,将删除所有者对象。后台级联删除(Background Cascading Deletion):这种删除策略会简单很多,它会立即删除所有者的对象,并由垃圾回收器在后台删除其从属对象。这种方式比前台级联删除快的多,因为不用等待时间来删除从属对象。

孤儿删除

孤儿删除策略(orphan deletion strategy)中,会直接删除所有者对象,并将从属对象中的 ownerReference 元数据设置为默认值。之后垃圾回收器会确定孤儿对象并将其删除。

垃圾回收器如何工作?

如果对象的 OwnerReferences 元数据中没有任何所有者对象,那么垃圾回收器会删除该对象。垃圾回收器由 Scanner、Garbage Processor 和 Propagator 组成

Scanner:它会检测 K8s 集群中支持的所有资源,并通过控制循环周期性地检测。它会扫描系统中的所有资源,并将每个对象添加到"脏队列"(dirty queue)中。

Garbage Processor:它由在"脏队列"上工作的 worker 组成。每个 worker 都会从"脏队列"中取出对象,并检查该对象里的 OwnerReference 字段是否为空。如果为空,那就从“脏队列”中取出下一个对象进行处理;如果不为空,它会检测 OwnerReference 字段内的 owner resoure object 是否存在,如果不存在,会请求 API 服务器删除该对象。

Propagator:用于优化垃圾回收器,它包含以下三个组件:

  • EventQueue:负责存储 k8s 中资源对象的事件
  • DAG(有向无环图):负责存储 k8s 中所有资源对象的 owner-dependent 关系
  • Worker:从 EventQueue 中取出资源对象的事件,并根据事件的类型会采取操作

在有了 Propagator 的加入之后,我们完全可以仅在 GC 开始运行的时候,让 Scanner 扫描系统中所有的对象,然后将这些信息传递给 Propagator 和“脏队列”。只要 DAG 一建立起来之后,那么 Scanner 其实就没有再工作的必要了。总体而言,K8s 中 GC 的实现是非常通用且非常有效,希望这篇文章可以帮助大家更加了解 K8s 中的 GC。

原文请点击:https://mp.weixin.qq.com/s/zhygwHbdK1h7sViHWN93hw