容器化部署现在已经是标配了。但说实话很多人在容器里跑应用时对I/O这块的关注度远不如CPU和内存。我见过不少线上事故都是因为容器I/O没管好结果一个“吵闹的邻居”把整个宿主机的磁盘打满。今天我们就来聊聊容器环境下的I/O。核心就两个东西一个是Docker的存储驱动overlayfs另一个是cgroup的blkio限制。搞懂了这两个你基本就能把容器I/O的底裤看穿了。21.1 overlayfs分层存储的“障眼法”Docker镜像之所以能分层复用靠的就是overlayfs。它本质上是一种联合文件系统把多个目录“叠”在一起对外呈现为一个统一的视图。我个人习惯把overlayfs理解为“透明胶带便利贴”的组合。底层是只读的镜像层你往上写东西时其实是在一个可读写层里做“覆盖”。读的时候如果上层有就读上层的上层没有才往下层找。核心要点overlayfs的写操作会触发“copy-up”行为。也就是当你第一次修改一个底层文件时内核会把文件从只读层拷贝到可读写层然后再修改。这个拷贝操作就是容器写性能的瓶颈所在。我曾经在压测一个日志采集容器时发现它的写延迟忽高忽低。排查了半天最后发现是因为容器内频繁修改一个位于镜像层的大配置文件每次修改都触发copy-up把几百MB的文件从底层拷上来。嗯这就是典型的“写放大”问题。21.1.1 overlayfs的I/O路径我们来看一下数据在overlayfs中的流动路径应用进程发起write() ↓ VFS层虚拟文件系统 ↓ overlayfs判断文件是否在upper层 ├── 在upper层 → 直接写入upper层 └── 不在upper层 → 触发copy-up将文件从lower层拷贝到upper层再写入 ↓ 底层文件系统通常是xfs或ext4 ↓ 块设备层最终落盘这个路径里最耗时的就是copy-up。你想想看本来只想改一个字节结果要把整个文件拷贝一遍。如果文件很大或者并发修改很多I/O压力瞬间就上去了。避坑指南我曾经遇到一个案例容器内频繁修改/var/log下的日志文件而这些日志文件是从基础镜像继承来的。每次写日志都触发copy-up导致磁盘I/O飙升。解决方案很简单把日志目录挂载为volume绕开overlayfs的分层机制。21.2 cgroup blkio给容器I/O上缰绳CPU和内存有cgroup限制I/O当然也有。blkio子系统就是干这个的。它主要提供两种限制方式权重限制blkio.weight按比例分配I/O带宽适合多个容器共享磁盘的场景。上限限制blkio.throttle硬性限制读写速率适合需要保证SLA的场景。我个人更倾向于用权重限制。为什么呢因为上限限制设得太死容易造成资源浪费设得太松又起不到限制作用。权重限制则灵活得多大家按比例分谁也别抢谁的。21.2.1 权重限制实战假设我们有两个容器想让它们的磁盘I/O比例为2:1# 容器A权重200 echo 8:0 200 /sys/fs/cgroup/blkio/docker/containerA/blkio.weight # 容器B权重100 echo 8:0 100 /sys/fs/cgroup/blkio/docker/containerB/blkio.weight这里的“8:0”是设备号对应主设备号8、次设备号0通常是sda。你可以用ls -l /dev/sda查看。注意权重限制只在设备有I/O竞争时才生效。如果磁盘空闲容器可以跑满带宽。说白了它是个“软限制”不是“硬限制”。21.2.2 上限限制实战如果你需要硬性限制那就用throttle# 限制读速为10MB/s echo 8:0 10485760 /sys/fs/cgroup/blkio/docker/container/blkio.throttle.read_bps_device # 限制写速为5MB/s echo 8:0 5242880 /sys/fs/cgroup/blkio/docker/container/blkio.throttle.write_bps_device单位是字节/秒。这里设的是10MB/s和5MB/s。注意这个限制是绝对的不管磁盘有没有竞争容器都不能超过这个值。我记得有一次帮客户排查数据库容器的性能问题。他们的数据库跑在容器里但业务高峰期I/O延迟特别高。后来发现是宿主机上另一个日志采集容器在疯狂写盘把带宽全占了。我们用blkio给日志容器加了权重限制数据库容器的延迟立刻就降下来了。21.3 容器I/O性能分析工具光有限制还不够你得能监控和诊断。我常用的工具组合是工具用途常用命令iostat查看宿主机磁盘I/O整体情况iostat -x 1blkio cgroup文件查看容器实际I/O使用量cat blkio.throttle.io_service_bytesdocker stats快速查看容器资源使用docker stats --no-streamperf分析I/O热点和延迟perf record -e block:block_rq_issue我个人习惯先用docker stats扫一眼如果发现某个容器的I/O异常高再进到cgroup目录里看详细数据。最后用perf定位具体是哪个进程在搞事。21.4 核心知识体系下面这张图总结了容器I/O的核心逻辑21.5 常见问题与调优建议最后我总结几个容器I/O的常见坑和解决办法写放大问题避免在容器内频繁修改镜像层的大文件。把可变数据挂载为volume或tmpfs。blkio限制不生效检查内核是否开启了CONFIG_BLK_CGROUP。有些云厂商的定制内核可能没开。iostat看到的I/O和容器内不一致因为overlayfs的copy-up操作发生在宿主机层面容器内看不到。所以要以宿主机数据为准。权重限制下某个容器仍然占满I/O检查是否还有其他进程在竞争。权重只在有竞争时生效。个人经验我曾经在Kubernetes集群里遇到一个诡异问题某个Pod的I/O限制明明设了但就是不起作用。查了半天发现是cgroup v1和v2混用导致的。Kubernetes默认用cgroup v2但blkio在v2下的接口路径和v1完全不同。嗯这里要注意不同内核版本和容器运行时cgroup的路径和接口可能有差异。好了关于容器环境I/O核心就是overlayfs的写时拷贝机制和cgroup blkio的限制策略。搞懂这两个你就能在容器化部署中游刃有余了。