kubelet 原理解析六： 垃圾回收

2020-03-27  本文已影响0人  徐亚松_v

概述

在k8s中节点会通过docker pull机制获取外部的镜像，那么什么时候清除镜像呢？k8s运行的容器又是什么时候清除呢?

Kubelet会定期进行垃圾回收（Garbage Collection），以清理节点上的无用镜像和容器。

截止到 v1.15 版本，垃圾回收间隔时间还都是在源码中固化的，不可自定义配置，如果节点上已经运行了 Kubelet，不建议再额外运行其它的垃圾回收工具，因为这些工具可能错误地清理掉 Kubelet 认为本应保留的镜像或容器，从而可能造成不可预知的问题。

容器的回收

docker容器的本质是宿主机上的一个进程，为了将容器做差异化的封装，docker借助于类似AUFS之类的文件系统做了很多事情。容器停止执行后，这些文件系统并不会自动清除，通过docker ps -a也能够看到这些资源（这是为了下次可以快速启动）。kubelet有一套container gc的方案，专门用于清理宿主机上的非所需容器。

另外，容器镜像较耗存储资源，但是每一台k8s node的存储空间都是有限的，kubelet上运行的pod生命周期可能很短，但是每个pod可能都使用不同的镜像，这就会导致宿主机上会留下很多不再需要的容器镜像，为了将有限的空间腾出来高效利用，kubelet设计了一套image gc的方案。

image

GC机制即将被eviction替代，在kubelet参数中已经有对应的提示信息。

容器GC的业务逻辑主要在(m *kubeGenericRuntimeManager)GarbageCollect中，主要是三个参数：

容器回收过程如下:

  1. 顶层函数会每分钟被调用，触发container gc操作；
  2. 该操作会以container的结束时间是否超过gcPolicy.MinAge为依据，查询出那些满足条件的容器，并组织成为按照pod为key，container列表为值的字典；这一步并没有做实际删除，但是其操作结果为后两部奠定了数据依据；
  3. 对字典中的每个pod的container做处理，找出该pod超过gcPolicy.MaxPerPodContainer的容器，然后对它们按照结束时间排序，执行删除，保障每个pod下已结束的container数满足配置参数；
  4. 经过上一部的删除后，针对node来讲，如果节点上待删除的容器数依然大于gcPolicy.MaxContainers, 就执行反向的运算。把node允许保留的最大容器数平分给每个pod，再按照该标准对每个pod执行一轮删除；
  5. 如果依然还不满足要求的数量，就不再按照pod做key，直接将所有的container拍扁平，按照时间顺序先删除最旧的容器，直到满足总数小于gcPolicy.MaxContainers。
image

镜像的回收

镜像回收主要参数：

具体流程比较简单；

  1. 与容器GC比较起来，镜像GC顶层函数被触发的周期更长，为5分钟触发一次。
  2. 通过cadvisor获取到节点上imageFS的详情，得到capacity、avaiable，据此推算磁盘使用率等信息；
  3. 当磁盘使用率大于image-gc-high-threshold参数中指定的值时，触发镜像的GC操作；
  4. 找出当前未被使用的镜像列表并按时间排序，过滤掉那些小于minimum-image-ttl-duration的镜像；
  5. 正式从节点上删除镜像；每次都比较是否删除的镜像数以满足所需释放的bytesToFree，若满足就停止删除。

参考

上一篇 下一篇

猜你喜欢

热点阅读