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   

K8S的镜像
清理办法

nerdctr -n k8s.io images prune -a

清理没有在用的镜像，但镜像在用的就清不了，在生产上，如果出现大量的持续集成的镜像更换，考虑定时执行清理无用镜像的cronjob

PV(persistent volume持久化存储)

hostpath

1. HostPath 类型 PV 存储容量过大

   在某些Kubernetes集群配置中，可能使用了hostPath类型的持久化卷插件，比如Rancher提供的hostPath StorageClass。在这种情况下，会在宿主机上指定一个目录作为持久化存储的位置，例如 /opt/local-path-provisioner。当这个目录下的数据量持续增长，可能会导致存储空间占用过大。

   处理方法：

   1. 确认已分配的PersistentVolumeClaims (PVC)：
      • 首先，通过 kubectl get pvc 查看所有已创建的PersistentVolumeClaim，并找到那些关联到hostPath类型PV的PVC。确认它们是否仍然被正在运行的Pod所使用。
   2. 检查Pod与PVC的关系：
      • 使用 kubectl get pods --show-labels 查找具有对应PVC标签的Pod，确定哪些Pod正在使用过大的PV。
   3. 数据迁移或清理：
      • 如果该存储空间内有重要数据，需要先将其备份或迁移至其他存储位置。
      • 若数据不再需要，则可以直接在宿主机上安全地删除数据。
   4. 解除Pod与PVC的绑定：
      • 先删除引用该PVC的Pod，让Pod停止运行并释放PVC。
      • 或者，如果Pod可以动态调整存储，可尝试缩小PVC的存储请求。
   5. 清理PersistentVolumeClaim (PVC)：
      • 删除不再需要的PVC，执行 kubectl delete pvc <pvc-name>。
   6. 清理PersistentVolume (PV)：
      • 当PVC被删除后，Kubernetes会根据回收策略自动清理关联的PV。对于hostPath类型的PV，这意味着宿主机上的指定目录将会空置出来，但有时仍需手动清理残留文件。(对应PVC的删除策略，Retain，Delete，默认是delete)
      • 如果PV未被自动清理，可通过查看PV状态 (kubectl get pv) 并手动删除对应的PV (kubectl delete pv <pv-name>)，然后清理宿主机上的实际存储路径。

分布式存储如longhorn

1. 副本数量调整：
   - 默认3副本，所以PV可能比原来大3倍（但是可以压缩部分）。
   - 使用Longhorn，可以通过其UI或YAML配置来更改卷的副本数量。调整前务必确保有足够的空间进行重新同步和数据迁移，以及评估对性能的影响。
2. 清理未使用资源：
   - 列出所有的PersistentVolumeClaim（PVC）和相关的PersistentVolumes（PV），识别并清理那些已经不再被任何Pod使用的PVC。一旦PVC被删除，Longhorn会自动根据其回收策略回收对应的PV，从而释放存储空间。
   - 登录到Longhorn管理界面，检查所有卷的状态，找出闲置或已废弃的卷，并采取相应的清理措施。
3. 扩容或缩容存储卷：
   - 如果有正在使用的卷接近满载，但未来还需要保留数据，可以考虑扩容这些卷，前提是底层存储允许。
   - 若卷内数据不再需要长期保存，也可以选择缩小其大小，前提是数据已经被妥善备份或迁移。
4. Snapshot 和 Backup 管理：
   - 验证是否有过多的快照或备份占用额外的存储空间。Longhorn支持周期性备份策略，确保只有包含新数据的备份才会被创建，并且无效的快照会被自动清理。
   - 通过Longhorn UI，可以手动删除不再需要的备份和快照，从而回收空间。
5. 监控与告警：
   - 设置和配置Longhorn的监控功能，以便及时获取存储空间使用率的警告信息，从而能够在存储空间即将耗尽之前采取行动。
6. 资源优化与规划：
   - 根据业务需求和集群资源情况，合理规划存储资源分配，确保资源的有效利用，例如采用适当的QoS策略限制过度消耗存储资源的应用程序。