Linux CPU iowait高怎么办？——K8s环境overlayfs存储驱动排查实战笔记

在Kubernetes集群运维中，我们时常会遇到节点CPU使用率中的iowait指标异常飙高，导致容器响应变慢、应用卡顿。这种现象往往与存储I/O密切相关，尤其是在使用overlayfs作为容器存储驱动时，由于写时复制（CoW）和镜像层叠加的特性，很容易引发意想不到的性能瓶颈。本文将从零开始，带你完整排查Linux iowait高的问题，并深入K8s overlayfs的工作原理，最终给出优化方案。

1. 什么是iowait？

iowait是CPU处于空闲状态但系统有未完成的磁盘I/O请求的时间占比。简单说，就是CPU在等待磁盘读写完成时无事可做。高iowait通常意味着磁盘响应太慢，或者I/O请求过于密集，导致CPU被阻塞。在容器环境中，这可能由容器频繁读写、镜像层过多、存储驱动效率低等原因引起。

2. overlayfs与K8s的关联

overlayfs是一种联合文件系统，Kubernetes容器运行时（如containerd、Docker）默认采用它来构建镜像层和容器层。它通过将多个目录（lower层、upper层、work层）叠加，实现容器的分层存储。这种设计节省了磁盘空间，但也带来写时复制开销：当容器修改文件时，overlayfs会将文件从lower层复制到upper层，这一过程会产生I/O操作。如果应用频繁写入小文件，或镜像层数过多，就可能引发容器存储性能问题，进而导致iowait升高。

3. 高IO排查实战步骤

当发现节点Linux iowait高时，可以按照以下流程逐步定位原因：

3.1 确认iowait指标

执行top或vmstat 1查看wa列是否持续偏高。再用iostat -x 1观察具体磁盘的await、svctm、util等指标，判断是哪个磁盘繁忙。

3.2 定位高I/O进程

使用iotop或pidstat -d 1找到读写频繁的进程ID。这些进程通常属于某个容器，可通过docker inspect或crictl inspect反查容器名称。

3.3 检查overlayfs目录

进入容器的存储目录（如/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/），查看overlayfs的挂载详情：cat mountinfo。重点关注upper层所在的磁盘分区是否和系统盘共用，如果独立磁盘性能不足也可能导致iowait。

3.4 深入分析overlayfs行为

overlayfs的写时复制机制会在以下场景触发额外I/O：大量小文件写入、目录重命名、日志滚动。可以使用strace -p 跟踪系统调用，或使用blktrace分析块设备I/O模式。如果发现大量copy up操作（将lower层文件复制到upper层），基本可判定是overlayfs带来的开销。

4. 解决方案与优化建议

针对K8s overlayfs引发的高IO排查结果，可以采取以下措施改善容器存储性能：

• 优化应用写入模式：减少频繁写入小文件，使用缓冲区或批量写入。
• 使用内存存储：对于临时数据，在Pod中设置emptyDir.medium: Memory，将写入重定向到tmpfs，避免磁盘I/O。
• 调整overlayfs挂载选项：新版内核支持metacopy=on和redirect_dir=on，可减少copy up操作，但需评估兼容性。
• 更换存储驱动：在极端场景下，可考虑使用fuse-overlayfs或直接挂载块存储（如AWS EBS、Ceph RBD）给容器。
• 监控与日志：定期采集节点磁盘性能指标，设置告警，及时发现iowait异常。

5. 总结

Linux CPU iowait高是K8s环境中常见且棘手的性能问题，理解overlayfs的工作机制是排查的关键。通过本文的步骤，你可以从现象到根源逐步分析，并找到适合自己场景的优化方案。希望这篇笔记能帮助你在未来的Linux iowait排查中少走弯路。

—— 实践出真知，排查笔记持续更新