什么是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