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
-
封锁节点,先让节点变的不可调度
kubectl cordon
-
对节点执行维护操作之前(例如:内核升级,硬件维护等),您可以使用 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
-
HostPath 类型 PV 存储容量过大
在某些Kubernetes集群配置中,可能使用了
hostPath
类型的持久化卷插件,比如Rancher提供的hostPath StorageClass。在这种情况下,会在宿主机上指定一个目录作为持久化存储的位置,例如/opt/local-path-provisioner
。当这个目录下的数据量持续增长,可能会导致存储空间占用过大。文章来源:https://www.toymoban.com/news/detail-851273.html处理方法:文章来源地址https://www.toymoban.com/news/detail-851273.html
-
确认已分配的PersistentVolumeClaims (PVC):
- 首先,通过
kubectl get pvc
查看所有已创建的PersistentVolumeClaim,并找到那些关联到hostPath类型PV的PVC。确认它们是否仍然被正在运行的Pod所使用。
- 首先,通过
-
检查Pod与PVC的关系:
- 使用
kubectl get pods --show-labels
查找具有对应PVC标签的Pod,确定哪些Pod正在使用过大的PV。
- 使用
-
数据迁移或清理:
- 如果该存储空间内有重要数据,需要先将其备份或迁移至其他存储位置。
- 若数据不再需要,则可以直接在宿主机上安全地删除数据。
-
解除Pod与PVC的绑定:
- 先删除引用该PVC的Pod,让Pod停止运行并释放PVC。
- 或者,如果Pod可以动态调整存储,可尝试缩小PVC的存储请求。
-
清理PersistentVolumeClaim (PVC):
- 删除不再需要的PVC,执行
kubectl delete pvc <pvc-name>
。
- 删除不再需要的PVC,执行
-
清理PersistentVolume (PV):
- 当PVC被删除后,Kubernetes会根据回收策略自动清理关联的PV。对于hostPath类型的PV,这意味着宿主机上的指定目录将会空置出来,但有时仍需手动清理残留文件。(对应PVC的删除策略,Retain,Delete,默认是delete)
- 如果PV未被自动清理,可通过查看PV状态 (
kubectl get pv
) 并手动删除对应的PV (kubectl delete pv <pv-name>
),然后清理宿主机上的实际存储路径。
-
确认已分配的PersistentVolumeClaims (PVC):
分布式存储如longhorn
-
副本数量调整:
- 默认3副本,所以PV可能比原来大3倍(但是可以压缩部分)。
- 使用Longhorn,可以通过其UI或YAML配置来更改卷的副本数量。调整前务必确保有足够的空间进行重新同步和数据迁移,以及评估对性能的影响。 -
清理未使用资源:
- 列出所有的PersistentVolumeClaim(PVC)和相关的PersistentVolumes(PV),识别并清理那些已经不再被任何Pod使用的PVC。一旦PVC被删除,Longhorn会自动根据其回收策略回收对应的PV,从而释放存储空间。
- 登录到Longhorn管理界面,检查所有卷的状态,找出闲置或已废弃的卷,并采取相应的清理措施。 -
扩容或缩容存储卷:
- 如果有正在使用的卷接近满载,但未来还需要保留数据,可以考虑扩容这些卷,前提是底层存储允许。
- 若卷内数据不再需要长期保存,也可以选择缩小其大小,前提是数据已经被妥善备份或迁移。 -
Snapshot 和 Backup 管理:
- 验证是否有过多的快照或备份占用额外的存储空间。Longhorn支持周期性备份策略,确保只有包含新数据的备份才会被创建,并且无效的快照会被自动清理。
- 通过Longhorn UI,可以手动删除不再需要的备份和快照,从而回收空间。 -
监控与告警:
- 设置和配置Longhorn的监控功能,以便及时获取存储空间使用率的警告信息,从而能够在存储空间即将耗尽之前采取行动。 -
资源优化与规划:
- 根据业务需求和集群资源情况,合理规划存储资源分配,确保资源的有效利用,例如采用适当的QoS策略限制过度消耗存储资源的应用程序。
到了这里,关于K8S node磁盘清理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!