K8S node磁盘清理_containerd snapshotter(2)，2024年BATJ30套大厂Linux运维经典高频面试题

这个命令不能覆盖所有的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策略限制过度消耗存储资源的应用程序。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Linux运维工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Linux运维知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip1024b （备注Linux运维获取）

一个人可以走的很快，但一群人才能走的更远。如果你从事以下工作或对以下感兴趣，欢迎戳这里加入程序员的圈子，让我们一起学习成长！

AI人工智能、Android移动开发、AIGC大模型、C C#、Go语言、Java、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算

a、Linux运维、云计算、MySQL、PMP、网络安全、Python爬虫、UE5、UI设计、Unity3D、Web前端开发、产品经理、车载开发、大数据、鸿蒙、计算机网络、嵌入式物联网、软件测试、数据结构与算法、音视频开发、Flutter、IOS开发、PHP开发、.NET、安卓逆向、云计算**