一、前言

      一说到GC，很多人(包括我在内)第一反应是内存的垃圾回收，尤其是javaer们，面试最爱考的八股文就是java的垃圾回收。不过今天要说的这个k8s的GC和java的不是一回事。你可以理解为广义的垃圾回收，因为在k8s的世界里，万物皆是资源。而GC就是回收资源。Kubelet的GC功能将清理未使用的image和container。Kubelet每分钟对container执行一次GC，每5分钟对image执行一次GC。

二、k8s GC机制

      K8s 实现了一种「Cascading deletion」（级联删除）的机制，它利用已经建立的「从属关系」进行资源对象的清理工作。例如，当一个 dependent 资源的 owner 已经被删除或者不存在的时候，从某种角度就可以判定，这个 dependent 的对象已经是异常（无人管辖）的了，需要进行清理。而 「cascading deletion」则是被 k8s 中的一个 controller 组件实现的：Garbage Collector。k8s 是通过 Garbage Collector 和 ownerReference 一起配合实现了「垃圾回收」的功能。

一个 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 中

 三、参考资料

1. https://www.cnblogs.com/xiaoyaojinzhazhadehangcheng/p/11605950.html