Linux命令效率与K8s排障：从管道思维到集群实战

1. 合集六开篇之前，先把 Linux 命令效率这个老问题说透

这是我整理“Linux & Kubernetes 必学知识点合集”的第六篇。前几篇我分别梳理过系统启动、网络排查、容器运行时、存储挂载等方向，这篇不想继续按目录平铺，而是想聊一聊那些“看起来很简单，却在日常实操和面试交流中被反复拿出来讨论”的知识点。每个点我都会尽量把原理、排查链路和实际命令放到一起讲，而不是只丢结论。

之所以把“Linux命令效率”放在最前面，是因为我发现不少人虽然背了很多命令参数，但真正在处理服务器问题时速度并不快。问题往往不在“记没记住”，而在“有没有形成组合命令的习惯”。老手和新手拉开差距的地方，通常不是某个冷门参数，而是对管道、过滤器和文本处理工具的运用方式。

1.1 你缺的不是命令大全，而是管道思维

很多教程喜欢列出 100 条常用 Linux 命令，单看每条命令都很简单，可真到了生产环境，几乎没有哪个需求能靠单条命令完成。比如分析 Nginx 访问日志，最常见的需求是统计访问量 TOP 10 的来源 IP。新手可能会一条条查日志，或者在 Excel 里手工数；老手写出来就是这么一行：

bash复制awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 10

这行命令看起来简单，但里面包含了四个独立的处理动作：awk 负责从每一行日志中提取第一个字段作为 IP；sort 把相同 IP 排到一起；uniq -c 负责统计连续重复的行并计数；sort -rn 再按计数从大到小排列；最后 head 取前 10 行。整个过程像一条流水线，每个工具只负责一件事，再把结果交给下一个工具。

我见过不少人卡在“为什么要 sort 两次”这个问题上。uniq 去重统计的前提是相同内容必须连续，如果不先 sort，uniq 统计出的结果大概率是错的。这是管道思维中很典型的一点：不是会几个命令就行，而是要理解每个工具对输入格式有什么要求，然后主动为下一个工具准备合适的输入。

再举一个更贴近运维场景的例子。线上有一批配置文件需要批量把 IP 从旧地址改成新地址，新手会打开 vim 一个文件一个文件地改，老手会直接这样：

bash复制find /etc/myapp -type f -name "*.conf" -exec sed -i 's/192.168.1.10/192.168.2.20/g' {} \;

这条命令里的 find 负责找出符合条件的文件，-exec 把查到的每一个文件传给 sed 处理，sed 在 -i 参数下直接原地替换。如果不放心先看看哪些文件会被改动，可以先去执行不含 sed 的 find 部分，把文件列表打印出来确认一遍。这个习惯很重要，批量操作前先“空跑”一遍，能为你挡掉至少一半误操作。

1.2 把查找、批量替换和存档变成一条命令

管道思维还能帮你处理更复杂的组合场景，比如“把今天改过的配置打包备份”。如果你总是先一层一层 cd 进目录找文件，再手动打 tar，很容易漏掉那些分布在不同位置的配置。我的做法是用 find 按时间过滤，直接喂给 tar：

bash复制find /etc /opt/myapp -type f -mtime -1 -print0 | xargs -0 tar czf /backup/conf_$(date +%F).tar.gz

这里有一个容易踩的坑：如果文件名或目录名包含空格，直接用 xargs 会导致参数被错误拆开，必须用 -print0 和 xargs -0 组合，让文件名以空字符分隔而不是换行或空格分隔。在生产服务器上，目录名带空格的情况其实不少，文件系统本身允许这样做，只是命令行处理时需要多做一步防护。

另外我特别想建议每个做运维的人都建立一套属于自己的“命令备忘录”，而不是收藏一堆别人整理的“命令大全”。最简单的做法是利用 history：

bash复制history | grep "kubectl rollout"

这一条命令能帮你把之前用过的滚动更新操作原样翻出来，避免每次都要重新回忆参数，也避免因为一条命令不确定就在生产环境里翻来覆去试。只要命令被敲过一次，就有机会被检索到；偶尔还会发现一些当时写得很漂亮的长命令，顺手整理进自己的笔记。长期积累下来，这套备忘录比任何外部文档都贴合你手头这批机器的实际情况。

2. 磁盘“满了”却删不掉文件？一次讲清排查链路

Linux 服务器上有个出现频率极高的故障：应用突然报错说“No space left on device”，你上去一看 df -h 确实显示磁盘满了，但各个目录用 du 统计下来，加起来又没有占这么多，感觉空间“不翼而飞”。这类问题我在不同环境里遇过很多次，把完整的排查链路整理出来，下次遇到基本可以按图索骥。

2.1 三步定位法：空间满了先分清这几种情况

看到磁盘满后，第一步不是急着删文件，而是先弄清到底是哪种“满”。我一般按下面这个顺序执行：

bash复制df -h
df -i
du -sh /* 2>/dev/null | sort -hr | head -n 20

df -h 看的是块设备容量使用率，df -i 看的是 inode 使用率。两者可能完全不同：一个 100GB 的磁盘，如果上面堆了上百万个 1KB 的小文件，容量可能只用了 50%，但 inode 已经耗尽，系统同样会报“No space left on device”。而 du 统计的是目录树中的实际文件大小，如果磁盘上有文件被删除但还被进程持续占用，du 统计不出来这部分空间，df 却能看到它在使用。

这三个命令的输出一定要放在一起看。我的经验是，先看容量满没满；如果容量没满但 inode 满了，走小文件清理方向；如果容量和 inode 都正常，应用却报磁盘满，那就要查是不是挂载点被覆盖、是不是有已删除未释放的文件，甚至是不是文件系统本身出了问题。单靠一个 df -h 就下结论，很容易把方向带偏。

2.2 inode 耗尽：目录里有海量小文件

inode 耗尽最典型的现象是 df -h 显示还有几十 GB 空闲，但提示符下连临时文件都创建不了。常见的元凶有这几个：邮件服务器队列目录 /var/spool/postfix/maildrop、系统日志定时任务产生的碎片文件、Docker overlay2 目录下残留的临时层、还有应用自己写的缓存目录。

定位问题目录时，可以逐级使用 du 和 find