解读

国内互联网大促、秒杀、日志采集等场景常出现“写放大”：容器内持续写小文件（缓存、日志、临时上传），Overlay2 的 upperdir 采用 ext4/xfs 的 inode 索引，一旦耗尽则触发 “No space left on device”，但 df -h 却显示磁盘未满。面试官想确认你是否理解 Overlay2 的 inode 双层消耗机制（镜像层+可写层），并能在不中断业务的前提下给出可落地的组合拳。

知识点

1. Overlay2 写时复制：首次修改即向 upperdir 新建 inode，小文件=高 inode 消耗。
2. ext4 默认 inode 数量按块大小固定比例创建，无法在线扩容；xfs 可 xfs_growfs -m 在线扩 inode，但需提前格式化。
3. kubelet 的 --image-gc-high-threshold 仅回收磁盘容量，不统计 inode，导致“有空间无 inode”时 GC 失效。
4. dir Nlink 索引限制：upperdir 单目录子项超 10 w 级时，rename 系统调用延迟飙高，与 inode 耗尽同步出现。
5. 国内云厂商 CSI 默认 ext4，控制台一键扩容仅扩容量不扩 inode，需手动重建 PV。

答案

“遇到 inode 耗尽，我会按 4 层 8 步 处理，确保高并发业务 30 秒内恢复：
① 急救：先 nsenter -t 1 -m -u -n -i 进入节点，通过 cat /proc/sys/fs/dentry-state 确认 inode 消耗速率；立即 echo 3 > /proc/sys/vm/drop_caches 释放已删除但仍占 inode 的 dentry，争取 2 分钟窗口。
② 快速释放：用 find /var/lib/docker/overlay2 -xdev -type f -links 1 -delete 清理 upperdir 中未被引用的零字节文件；对 Java 应用加 -XX:MaxGCPauseMillis 降低 GC 临时文件；把容器内 /tmp 挂载为 tmpfs，把 30% 小文件流量从磁盘转到内存，inode 占用瞬间下降 20%。
③ 在线扩容：若宿主机为 xfs，直接 xfs_growfs -m 30 /var/lib/docker 把 inode 比例从 25% 提到 30%，无需停容器；若是 ext4，则使用 volume migration：先通过 docker run --volumes-from 启动侧车容器，把旧卷 rsync 到提前格式化好的 高 inode 比值（-i 4096） 的新 PV，再 kubectl patch pv 完成无中断切换，整个过程 5 分钟。
④ 长效治理：
– 镜像侧：把 Dockerfile 中 RUN yum install 合并为单行并 yum clean all，减少镜像层 15%；业务包使用 multi-stage 丢弃构建依赖，镜像层 inode 占用降 40%。
– 运行时：日志使用 stdout + json-file log-driver + log-opt max-size=50m,max-file=5，禁止容器内写日志文件；对必须落盘的数据采用 hostPath 独立 xfs 卷，挂载参数 -n ftype=1,inode64，并开启 prjquota 做 project 级 inode 限流，单容器上限 200 万 inode。
– 平台侧：在 ACK/TKG 集群 中部署 node-problem-detector 采集 node_inode_almost_full 指标，Prometheus 告警阈值设 80%，提前 24 小时触发自动扩容；同时把 kubelet GC 策略改为 inodePercentage: 85，让 kubelet 在 inode 层面也参与回收。
通过上述组合拳，去年双 11 我们把单节点 inode 峰值从 99% 压到 65%，零故障完成 32 亿次写入。”

拓展思考

如果未来业务全面转向 Serverless 容器（如阿里 ECI、腾讯 TCR Serverless），节点不再由用户托管，inode 耗尽将转化为 平台级配额。此时需把优化重心前移到 镜像供应链：

1. 使用 CRFS/nydus 把镜像层拆分为 chunk，按需拉取，inode 占用与镜像大小解耦；
2. 在 CI 阶段引入 “inode budget” 门禁，单镜像 inode 增量超 5 k 即拒绝合并；
3. 对函数型负载采用 tmpfs+ro 根文件系统，写操作全部落入内存或对象存储，从根本上消除 inode 概念。