微信的微网站,微信公众号文章 转wordpress,重庆市住房和城乡建设岗位证书查询,内在空间官网K8S磁盘清理
K8S的部署形式相比传统非容器部署#xff0c;会消耗更多的磁盘#xff0c;在运行时可能会把磁盘占满。 这里以使用containerd运行时的K8S node为例#xff0c;说明磁盘会用到那里了和如何清理磁盘
通用处理
磁盘清理:
du -h --max-depth6 / 2/dev/nul…K8S磁盘清理
K8S的部署形式相比传统非容器部署会消耗更多的磁盘在运行时可能会把磁盘占满。 这里以使用containerd运行时的K8S node为例说明磁盘会用到那里了和如何清理磁盘
通用处理
磁盘清理:
du -h --max-depth6 / 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。当这个目录下的数据量持续增长可能会导致存储空间占用过大。 处理方法 确认已分配的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。 清理PersistentVolume (PV) 当PVC被删除后Kubernetes会根据回收策略自动清理关联的PV。对于hostPath类型的PV这意味着宿主机上的指定目录将会空置出来但有时仍需手动清理残留文件。(对应PVC的删除策略RetainDelete默认是delete)如果PV未被自动清理可通过查看PV状态 (kubectl get pv) 并手动删除对应的PV (kubectl delete pv pv-name)然后清理宿主机上的实际存储路径。
分布式存储如longhorn
副本数量调整 - 默认3副本所以PV可能比原来大3倍但是可以压缩部分。 - 使用Longhorn可以通过其UI或YAML配置来更改卷的副本数量。调整前务必确保有足够的空间进行重新同步和数据迁移以及评估对性能的影响。清理未使用资源 - 列出所有的PersistentVolumeClaimPVC和相关的PersistentVolumesPV识别并清理那些已经不再被任何Pod使用的PVC。一旦PVC被删除Longhorn会自动根据其回收策略回收对应的PV从而释放存储空间。 - 登录到Longhorn管理界面检查所有卷的状态找出闲置或已废弃的卷并采取相应的清理措施。扩容或缩容存储卷 - 如果有正在使用的卷接近满载但未来还需要保留数据可以考虑扩容这些卷前提是底层存储允许。 - 若卷内数据不再需要长期保存也可以选择缩小其大小前提是数据已经被妥善备份或迁移。Snapshot 和 Backup 管理 - 验证是否有过多的快照或备份占用额外的存储空间。Longhorn支持周期性备份策略确保只有包含新数据的备份才会被创建并且无效的快照会被自动清理。 - 通过Longhorn UI可以手动删除不再需要的备份和快照从而回收空间。监控与告警 - 设置和配置Longhorn的监控功能以便及时获取存储空间使用率的警告信息从而能够在存储空间即将耗尽之前采取行动。资源优化与规划 - 根据业务需求和集群资源情况合理规划存储资源分配确保资源的有效利用例如采用适当的QoS策略限制过度消耗存储资源的应用程序。
