背景：

早些时候 kubernetes 集群的 cri 还应用 docker 的时候经验过这样的情况：集群运行很久后硬盘跑的快满了 ……, 大文件次要集中在：/var/lib/docker/overlay2 下文件有快 70G，/var/log/journal/ 日志也有 4 -5G。过后的操作是手工的在 work 节点进行了一下的操作：

1. journalctl –vacuum-size=20M #设置 journal 日志最大为 20M 不保留不必要日志。
2. docker image prune -a –filter “until=24h” # 革除超过创立工夫超过 24 小时的镜像
3. docker container prune –filter “until=24h” #革除掉所有停掉的容器，但 24 内创立的除外
4. docker volume prune –filter “label!=keep” #除 lable=keep 外的 volume 外都清理掉 (没有援用的 volume)
5. docker system prune #清理 everything：images，containers，networks 一次性清理操作能够通过 docker system prune 来搞定

注：以上摘自集体博客 2019 年的一篇：https://duiniwukenaihe.github.io/2019/11/25/k8s-question2/。
当然了相似的还有 inotify watch 耗尽 cgroup 泄露。可参照：https://www.bookstack.cn/read/kubernetes-practice-guide/troubleshooting-problems-errors-no-space-left-on-device.md
那么问题来了：我当初的集群是 kubernetes1.21 集群。cri 是 containerd 我改如何清理除了系统日志外的 对于 cri 的资源呢？失常的来说 kubelet 是有此性能的？反正我 tke 集群的 work 节点最近频繁收到了磁盘大于百分之九十的报警了 ……，强迫症犯了！

对于 Kubernetes image 垃圾镜像容器的回收

对于 kubelet:

节点治理

节点通过设置 kubelet 的启动参数“–register-node”，来决定是否向 API Server 注册本人，默认为 true.[kubelet –help]

Pod 治理

kubelet 通过 API Server Client 应用 Watch/List 的形式监听 etcd 中 /registry/nodes/${以后节点名称} 和 /registry/pods 的 目录，将获取的信息同步到本地缓存中。kubelet 监听 etcd，执行对 Pod 的操作，对容器的操作则是通过 Docker Client 执行，常见的操作蕴含：增，删，该，查。

容器健康检查

探针是 kubelet 对容器执行定期的诊断，次要通过调用容器配置的三类 Handler 实现，如果存活探测失败，则
kubelet 会杀死容器，并且容器将受到其 重启策略的影响。

资源监控

kubelet 通过 cAdvisor 获取本节点信息及容器的数据。cAdvisor 为谷歌开源的容器资源剖析工具，默认集成到
kubernetes 中。

kubelet-garbage-collection

注：以下内容来自：https://kubernetes.io/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/ 嗯多看下文档 ……
​

垃圾回收是 kubelet 的一个有用性能，它将清理未应用的镜像和容器。Kubelet 将每分钟对容器执行一次垃圾回收，每五分钟对镜像执行一次垃圾回收。不倡议应用内部垃圾收集工具，因为这些工具可能会删除本来冀望存在的容器进而毁坏 kubelet 的行为。

镜像回收

Kubernetes 借助于 cadvisor 通过 imageManager 来治理所有镜像的生命周期。
镜像垃圾回收策略只思考两个因素：HighThresholdPercent 和 LowThresholdPercent。磁盘使用率超过下限
阈值（HighThresholdPercent）将触发垃圾回收。垃圾回收将删除最近起码应用的镜像，直到磁盘使用率满足下
限阈值（LowThresholdPercent）。

容器回收

容器垃圾回收策略思考三个用户定义变量。MinAge 是容器能够被执行垃圾回收的最小生命周期。
MaxPerPodContainer 是每个 pod 内容许存在的死亡容器的最大数量。MaxContainers 是全副死亡容器的最大数
量。能够分别独立地通过将 MinAge 设置为 0，以及将 MaxPerPodContainer 和 MaxContainers 设置为小于 0 来
禁用这些变量。Kubelet 将解决无奈辨识的、已删除的以及超出后面提到的参数所设置范畴的容器。最老的容器通常会先被移除。MaxPerPodContainer 和 MaxContainer 在某些场景下可能会存在抵触，例如在保障每个 pod 内死亡容器的最大数 量（MaxPerPodContainer）的条件下可能会超过容许存在的全副死亡容器的最大数量（MaxContainer）。MaxPerPodContainer 在这种状况下会被进行调整：最坏的状况是将 MaxPerPodContainer 降级为 1，并驱赶最老 的容器。此外，pod 内曾经被删除的容器一旦年龄超过 MinAge 就会被清理。
不被 kubelet 治理的容器不受容器垃圾回收的束缚。

用户配置

用户能够应用以下 kubelet 参数调整相干阈值来优化镜像垃圾回收：

1. image-gc-high-threshold，触发镜像垃圾回收的磁盘使用率百分比。默认值为 85%。
2. image-gc-low-threshold，镜像垃圾回收试图开释资源后达到的磁盘使用率百分比。默认值为 80%。

咱们还容许用户通过以下 kubelet 参数自定义垃圾收集策略：

1. minimum-container-ttl-duration，实现的容器在被垃圾回收之前的最小年龄，默认是 0 分钟。这意味着每个实现的容器都会被执行垃圾回收。
2. maximum-dead-containers-per-container，每个容器要保留的旧实例的最大数量。默认值为 1。
3. maximum-dead-containers，要全局保留的旧容器实例的最大数量。默认值是 -1，意味着没有全局限度。

容器可能会在其效用过期之前被垃圾回收。这些容器可能蕴含日志和其余对故障诊断有用的数据。强烈建议为 maximum-dead-containers-per-container 设置一个足够大的值，以便每个预期容器至多保留一个死亡容器。因为同样的起因，maximum-dead-containers 也倡议应用一个足够大的值。

参照一下我的 tke 集群

cat /etc/kubernetes/kubelet

看了一眼没有找到 kubelet-garbage-collection 下面的参数？只有一个 –eviction-hard。认真看一眼文档的弃用局部：

嗯 1.21 版本启用了 –eviction-hard 参数，至于 nodefs.inodesFree 可参照：https://kubernetes.io/zh/docs/tasks/administer-cluster/out-of-resource/

自建集群中的配置：

嗯配置文件中未作任何设置只有一个 imageMinimumGCAge！
可参照：

可参照：https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/。中文如下：

总结一下：

Kubelet 反对 gc 和驱赶机制，可通过 –image-gc-high-threshold、–image-gc-low-threshold、–eviction-hard、–eviction-soft 及 –eviction-minimum-reclaim 等参数进行管制以实现磁盘空间的开释。当配置不正确，或者节点上有其它非 K8S 治理的过程在一直写数据到磁盘，将会占用大量空间时将导致磁盘爆满。tke 集群设置的是 –eviction-hard=nodefs.available<10%，这个值我可能会批改为 20%。因为 cvm 的报警阀值我都设置的 90%。后续集体筹备参照 tke 的 –eviction-hard=nodefs.available<10%,nodefs.inodesFree<5%,memory.available<100Mi 参数批改一下这三个了 ……（image-gc-high-threshold 默认 85%，image-gc-low-threshold 默认 80% 自建的集群应该是 疏忽了）。集体的集群还没有报警。要害是 tke 集群的报警这个值还的调整一下了！

对于 tke 磁盘爆满的文档：

https://cloud.tencent.com/document/product/457/43126#.E5.8F.AF.E8.83.BD.E5.8E.9F.E5.9B.A0

另外 ubelet 的配置还要深入研究一下！

​