先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

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

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

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

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

另外也可以采用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   


### 最后的话

最近很多小伙伴找我要Linux学习资料，于是我翻箱倒柜，整理了一些优质资源，涵盖视频、电子书、PPT等共享给大家！

### 资料预览

给大家整理的视频资料：

![](https://img-blog.csdnimg.cn/img_convert/1eb3ece285dfb3d3611051bf69278b5b.png)

给大家整理的电子书资料：

  

![](https://img-blog.csdnimg.cn/img_convert/52daa09a7467138b5b158e651ee43832.png)



**如果本文对你有帮助，欢迎点赞、收藏、转发给朋友，让我有持续创作的动力！**


**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）**
![img](https://img-blog.csdnimg.cn/img_convert/5b73ad6a73f900a50c6fecf57c903a54.jpeg)

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
提升。**

**需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）**
[外链图片转存中...(img-pGcn1qN3-1713140412536)]

**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**