What is GC
GC Garbage Collector is short. From a functional level, it and programming languages among the "GC" is basically the same. It cleans Kubernetes in "meet certain conditions" Resource Object of.
Kubelet the GC function will clean up the image container and unused. Kubelet perform a GC for container per minute, every 5 minutes for the image to perform a GC. Garbage collection is not recommended to use an external tool, because these tools may damage Kubelet.
Basic knowledge kubernetes inside
- In k8s, you may think things are resources, a lot of logic operation object is Resource Object.
- Kubernetes maintain a certain degree of "affiliation" in a different Resource Objects. Built-in Resource Objects will generally default to establish a "subordinate relationship" between a Resource Object and its creator.
- You can also take advantage of
ObjectMeta.OwnerReferencesfree to build relationship to the two Resource Object, provided that the two objects are in a relationship must Namespace under. - K8s achieve a kind of "Cascading deletion" mechanism (cascading deletes), which uses the already established "affiliation" to clean up the work of the resource object. For example, when the owner of a dependent resource has been deleted or does not exist when, in some ways it can be determined that the dependent object is already abnormal (no jurisdiction) of the need to clean up. The "cascading deletion" is being implemented in a controller k8s components:
Garbage Collector - k8s by
Garbage CollectorandownerReferencewith the realization of a "garbage collection" function together.
kubernetes composed of gc
Garbage Collector generally realized by a three parts:
-
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