kubernetes里面的GC--转发

什么是GC

GC 是 Garbage Collector 的简称。从功能层面上来说，它和编程语言当中的「GC」基本上是一样的。它清理 Kubernetes 中「符合特定条件」的 Resource Object。

Kubelet的GC功能将清理未使用的image和container。Kubelet每分钟对container执行一次GC，每5分钟对image执行一次GC。不建议使用外部垃圾收集工具，因为这些工具可能破坏Kubelet。

kubernetes里面的基本常识

在 k8s 中，你可以认为万物皆资源，很多逻辑的操作对象都是 Resource Object。
Kubernetes 在不同的 Resource Objects 中维护一定的「从属关系」。内置的 Resource Objects 一般会默认在一个 Resource Object 和它的创建者之间建立一个「从属关系」。
你也可以利用ObjectMeta.OwnerReferences自由的去给两个 Resource Object 建立关系，前提是被建立关系的两个对象必须在一个 Namespace 下。
K8s 实现了一种「Cascading deletion」（级联删除）的机制，它利用已经建立的「从属关系」进行资源对象的清理工作。例如，当一个 dependent 资源的 owner 已经被删除或者不存在的时候，从某种角度就可以判定，这个 dependent 的对象已经是异常（无人管辖）的了，需要进行清理。而「cascading deletion」则是被 k8s 中的一个 controller 组件实现的：Garbage Collector
k8s 是通过 Garbage Collector 和 ownerReference 一起配合实现了「垃圾回收」的功能。

kubernetes的gc组成

一个 Garbage Collector 通常由三部分实现：

Scanner：它负责收集目前系统中已存在的 Resource，并且周期性的将这些资源对象放入一个队列中，等待处理（检测是否要对某一个Resource Object 进行 GC 操作）
Garbage Processor: Garbage Processor 由两部分组成
- Dirty Queue： Scanner 会将周期性扫描到的 Resource Object 放入这个队列中等待处理
- Worker：worker 负责从这个队列中取出元素进行处理
- - 检查 Object 的 metaData 部分，查看ownerReference字段是否为空
  - - 如果为空，则本次处理结束
    - 如果不为空，检测ownerReference字段内标识的 Owner Resource Object是否存在
    - - 存在：则本次处理结束
      - 不存在：删除这个 Object
Propagator： Propagator 由三个部分构成
- EventQueue：负责存储 k8s 中资源对象的事件（Eg：ADD，UPDATE，DELETE）
- DAG(有向无环图)：负责存储 k8s 中所有资源对象的「owner-dependent」关系
- Worker：从 EventQueue 中，取出资源对象的事件，根据事件的类型会采取以下两种操作
- - ADD/UPDATE: 将该事件对应的资源对象加入 DAG，且如果该对象有 owner 且 owner 不在 DAG 中，将它同时加入 Garbage Processor 的 Dirty Queue 中
  - DELETE：将该事件对应的资源对象从 DAG 中删除，并且将其「管辖」的对象（只向下寻找一级，如删除 Deployment，那么只操作 ReplicaSet ）加入 Garbage Processor 的 Dirty Queue 中

其实，在有了 Scanner 和 Garbage Processor 之后，Garbage Collector 就已经能够实现「垃圾回收」的功能了。但是有一个明显的问题：Scanner 的扫描频率设置多少好呢？太长了，k8s 内部就会积累过多的「废弃资源」；太短了，尤其是在集群内部资源对象较多的时候，频繁的拉取信息对 API-Server 也是一个不小的压力。

k8s 作为一个分布式的服务编排系统，其内部执行任何一项逻辑或者行为，都依赖一种机制：「事件驱动」。说的简单点，k8s 中一些看起来「自动」的行为，其实都是由一些神秘的「力量」在驱动着。而这个「力量」就是我们所说的「Event」。任意一个 Resource Object 发生变动的时候（新建，更新，删除），都会触发一个 k8s 的事件（Event），这个事件在 k8s 的内部是公开的，也就是说，我们可以在任意一个地方监听这些事件。

总的来说，无论是「事件的监听机制」还是「周期性访问 API-Server 批量获取 Resource Object 信息」，其目的都是为了能够掌握 Resource Object 的最新信息。两者是各有优势的：

批量拉取：一次性拉取所有的 Resource Object，全面
监听 Resource 的 Event：实时性强，且对 API—SERVER 不会造成太大的压力

综上所述，在实现 Garbage Collector 的过程中，k8s 向其添加了一个「增强型」的组件：Propagator

在有了 Propagator 的加入之后，我们完全可以仅在 GC 开始运行的时候，让 Scanner 扫描一下系统中所有的 Object，然后将这些信息传递给 Propagator 和 Dirty Queue。只要 DAG 一建立起来之后，那么 Scanner 其实就没有再工作的必要了。「事件驱动」的机制提供了一种增量的方式让 GC 来监控 k8s 集群内部的资源对象变化情况。

参考地址

https://mp.weixin.qq.com/s/6b5jdDkvmtywvcRa4MMjQA

https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kubelet/config/v1beta1/types.go

https://yq.aliyun.com/articles/679728

https://zhuanlan.zhihu.com/p/50101300