K8S磁盘清理

K8S的部署形式相比传统非容器部署，会消耗更多的磁盘，在运行时可能会把磁盘占满。
这里以使用containerd运行时的K8S node为例，说明磁盘会用到那里了和如何清理磁盘

通用处理

磁盘清理:

du -h --max-depth=6  /  2>/dev/null | sort -h | tail -n 200

查看是什么占用磁盘多

另外也可以采用Node exporter去持续收集节点的磁盘使用信息，但针对非PV效果一般

Node目录

在ssh登录到node上
在笔者的实践中，可能特别大的目录如下

K8S container Runtime

11G /run/containerd/io.containerd.runtime.v2.task/k8s.io

/run/containerd/io.containerd.runtime.v2.task/k8s.io 目录包含了K8S容器运行时的可读写层数据。当发现此目录占用过多磁盘空间时，可以首先定位占用空间最多的Pod，通过以下命令找出并进一步排查原因：

根因是容器往容器的rootfs里(也就是运行时的文件目录)写数据，如在容器中不挂载日志PV的情况下直接在容器写日志

查看是什么pod用得多，这里的码是容器的id

cd /run/containerd/io.containerd.runtime.v2.task/k8s.io
du -sh *|sort -h
400M    d69bae349b1ff1f9fd904d470eb257c40d8c2bca84c752f1c1b19687d4214836
470M    445155da8c81dbe5d99a295f70943516a8604793350166b60fbe13d79af55d69
895M    20cb3cad45f400d93d6865065510378e8e5445107606c63fd3c606e002da7a56
2.1G    32317ff26babc88a567c8824cc272d46d782b6c4fbf1d6136788baaabe857c49
2.1G    4689c5537759fcd97666718f6209364c736cfa4fe9bee04b1cb16702cbe9c807
2.1G    e298b8fc01463587c116ae5878828ed126a06b77973e0d502eee95eacca570f0

找排名前几位给查一下（不要粘贴完整的，因为默认的crictl ps不显示全部的，像最后一条完整的是e298b8fc01463587c116ae5878828ed126a06b77973e0d502eee95eacca570f0，如下的crictl ps只是显示到e298b8fc01463）
看到是rancher，没办法确实大，后续再处理

crictl ps|grep  e298b8fc0
#看到是rancher，没办法确实大
e298b8fc01463       cb636b91766c4       8 days ago          Running             rancher                                          0                   6b9c18fb0436d       rancher-64cf6ddd96-6d9v5

解决办法1，容器层面删除

尝试删除容器

crictl rm -f e298b8fc0
e298b8fc0
e298b8fc0

后续deployment等会重新将pod和容器拉起

解决办法2 kubectl删除pod

kubectl delete pod -n cattle-system rancher-64cf6ddd96-6d9v5

后续等待replica set重新拉起pod

节点级别删除所有pod使其重建，清理runtime

只是删除pod重建

kubectl get pods -o wide  -A | awk '/Running/{print $1,$2}'   | xargs -r -n2 kubectl delete pod --force -n

这个命令不能覆盖所有的pod状态，后续可以尝试修改，但这个命令也可以批量删除一些其他的异常pod，通过变更状态

更推荐下面的做法

节点级别的处理

cordon 停止调度
影响最小，只会将node调为SchedulingDisabled
之后再发创建pod，不会被调度到该节点
旧有的pod不会受到影响，仍正常对外提供服务

恢复调度

kubectl uncordon node_name

drain 驱逐节点
首先，驱逐node上的pod，其他节点重新创建
接着，将节点调为SchedulingDisabled

恢复调度
kubectl uncordon node_name

1. 封锁节点，先让节点变的不可调度

kubectl cordon
2. 对节点执行维护操作之前（例如：内核升级，硬件维护等），您可以使用 kubectl drain 安全驱逐节点上面所有的 pod。

安全驱逐的方式将会允许 pod 里面的容器遵循指定的 PodDisruptionBudgets 执行优雅的中止。
注： 默认情况下，kubectl drain 会忽略那些不能杀死的系统类型的 pod，如果您想了解更多详细的内容，请参考kubectl drain

kubectl drain 返回成功表明所有的 pod （除了前面排除的那些）已经被安全驱逐（遵循期望优雅的中止期，并且没有违反任何应用程序级别的中断预算）。

然后，通过对物理机断电或者在云平台上删除节点所在的虚拟机，都能安全的将节点移除。

根因解决

原因是容器在没有PV的挂载也写入的文件，如业务容器，rocketMQ容器，MySQL容器等往文件路径写入大量日志或者其他东西（如rancher的helm charts），考虑把日志的目录从pod里挂载出来，或者干脆直接阻止这个行为让容器只能在标准流输出日志

容器镜像

10G     /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs