用java做网络小说网站企业整站推广
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。当这个目录下的数据量持续增长，可能会导致存储空间占用过大。处理方法：
- 确认已分配的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策略限制过度消耗存储资源的应用程序。