业务日志写进 emptyDir：一次 sizeLimit 撞穿 + inode 耗尽的 6 小时排障与日志预算方案

结论先行：把「往 stdout 打日志」改成「往 Pod 里的 /var/log/app/ 写文件」之后，你多了一条独立的资源预算线——emptyDir 的 sizeLimit 和它落在节点根分区上的 inode 配额。这两条线在 CPU / 内存监控里完全不可见，撞墙的方式一个是应用收到 ENOSPC、一个是 ls 都列不出来。这篇文章复盘一次 6 小时的排障，给一套「logrotate 参数怎么配才不产生垃圾文件 + emptyDir 预算怎么算」的可抄方案。

一、现象与背景：日志目录 400MB「没超」，应用却集体写不动了

先交代环境，方便对号入座：

• 集群：16 节点（8C16G，系统盘 100GB），Kubernetes 1.28.9、containerd 1.7.13、cgroup v2、内核 5.15.0-91；
• 服务：Go 1.21 写的订单回调网关，单 Pod 规格 requests 1C / limits 2C、memory 512Mi，每个 Pod 挂了 emptyDir: {sizeLimit: 2Gi} 的日志卷，日志由应用自己写文件（lumberjack 风格轮转），不走 stdout；
• 事故：某次大促压测后，23 个 Pod 中有 19 个在 10 分钟内陆续出现 write /var/log/app/order.log: no space left on device，P50 从 12ms 涨到 340ms（日志写入路径在请求主链路上同步执行）。更诡异的是 df -h 显示 emptyDir 只用了 412MB / 2Gi，CPU、内存、节点磁盘水位全绿。

排查花了 6 小时，因为最初的三个假设全被数据否掉：不是节点盘满（nodefs.available 还有 41%）、不是 memory limit（working set 峰值 310Mi）、不是 conntrack（使用率 12%）。最后两条命令定位：

# 在 Pod 里
$ df -i /var/log/app
Filesystem       Inodes  IUsed IFree IUse% Mounted on
overlay       11796480 11796463     17  100% /var/log/app
$ ls /var/log/app | wc -l
38211

inode 用了 100%，只剩 17 个。 目录里有 3.8 万个文件，但 du -sh 合计只有 412MB——单文件平均 11KB。

二、根因：三条互相独立的预算线，我们只设了其中一条

这次事故是三个机制叠加，缺一不炸：

1. emptyDir 的 sizeLimit 只约束字节数，不约束 inode 数。 K8s 对 emptyDir 的 sizeLimit 是通过给该目录挂一个 tmpfs（或 cgroup 记账）实现的，超字节数后新写返回 ENOSPC。但文件个数没有上限，它消耗的是节点根分区的 inode 表——100GB 的 ext4 系统盘默认约 1180 万个 inode，3.8 万个文件本身不多，多的是 3.8 万个文件 × 16 节点上所有 Pod 的叠加，加上容器运行时自己的元数据，把该节点 inode 推到了 99.7%。inode 耗尽后，连「新建一个 1 字节文件」都失败——这就是字节水位 20% 却 ENOSPC 的原因。
2. logrotate 的 size + maxsize 组合在高频日志下会「每周期滚一个文件」。 我们的配置是 size 30M + maxsize 200M + rotate 10。语义是：每次 cron 周期（默认每天）检查，若当前日志 ≥30M 就滚，单文件封顶 200M。大促压测下这个网关日志增速约 8MB/min，意味着日志每 4 分钟过一次 30M 线——而应用层的轮转器（lumberjack）按 maxsize 200M 滚、保留 10 个，正常时一天 2~4 个文件；但压测期间进程被 OOM 之外的信号 SIGSTOP 过两次（节点 kubelet 卡顿），轮转 goroutine 卡死，旧文件没被删、新文件在滚，叠加 logrotate 每天再滚一轮，文件数按「天 × 滚转次数」累积，最终 3.8 万个。
3. 应用把「写日志失败」当成了可重试错误。 Go 侧的 logger 对 ENOSPC 走了通用的「重试 3 次」路径，每次重试间隔 200ms，而请求主链路是同步等 logger 的——一次写失败 = 一次 600ms+ 的延迟贡献。19 个 Pod 同时进入这个循环，P50 直接起飞。日志通道应该 fail-open（降级丢弃 + 计数），而不是 fail-closed（阻塞业务）。

三、具体做法：三层预算 + 一份可抄的配置

3.1 emptyDir 预算怎么算（先算账再配）

原则：sizeLimit ≥ 单 Pod 日志保留量，且「保留量 × 节点上同类 Pod 数」≤ 系统盘 inode 预算的 1/10。 具体：

# 单文件 50M × 保留 8 个 = 400MB，这就是 sizeLimit 的下限
volumes:
- name: app-log
  emptyDir:
    sizeLimit: 512Mi   # 400MB 保留量 + ~20% 余量

节点侧 inode 预算（一次性核对，tune2fs -l 或 df -i 看总量）：

# 100GB ext4 系统盘 ≈ 1179 万 inode
# 该节点 8 个日志 Pod × 每 Pod 上限 8 个文件 = 64 个文件，占比 < 0.01%
# 真正的风险是「轮转失控产生的僵尸文件」，所以下面第 3.2 节是关键

3.2 logrotate 配置（防「每周期滚一个文件」的核心）

/var/log/app/*.log {
    daily
    size 50M          # 达到 50M 且到点才滚，而不是「每周期检查到 >30M 就滚」
    maxsize 200M      # 单文件硬顶
    rotate 8          # 保留 8 个，与 emptyDir 512Mi 预算对齐
    missingok
    notifempty
    delaycompress
    compress
    create 0640 app app
    # 关键：不用 copytruncate（见第四节坑 2）
}

rotate 8 × 50M = 400MB，文件数量被 rotate 参数硬性封顶在 8 个——inode 消耗从此可计算、可预测。

3.3 应用侧：日志写失败必须 fail-open

// 伪代码：写日志路径上的错误处理
func (l *Logger) Write(p []byte) (int, error) {
    n, err := l.fw.Write(p)
    if err != nil {
        atomic.AddUint64(&l.dropCount, uint64(len(p))) // 只计数
        if errors.Is(err, syscall.ENOSPC) {
            l.degradeOnce() // 切换为采样模式（1/100），不重试、不阻塞
        }
        return len(p), nil // 对业务返回成功，日志降级
    }
    return n, nil
}
// 把 dropCount 暴露到 /metrics，接告警：log_dropped_bytes_total > 0 持续 1min 即 P2

四、踩过的坑（反直觉之处）

1. df -h 正常不代表能写，df -i 才是第二道闸。 我们监控里有 nodefs_available_bytes 但没有 nodefs_files_free——inode 使用率到 99% 时没有任何告警。给 node-exporter 加一个 node_filesystem_files{fstype!="tmpfs"} / node_filesystem_files_free 的比率告警（>85% 预警），成本 10 分钟。
2. copytruncate 在高频日志下会静默丢日志。 它的工作方式是「copy 到 .1 → 把原文件 truncate 为 0」，copy 和 truncate 之间应用继续写的行直接消失（不是进 .1，也不是留在原文件）。压测期间 8MB/min 的日志量，这个窗口丢 200~400 行是常态。宁可让应用支持 reopen（flock 检测 .1 文件出现后重开 fd），也不要 copytruncate。
3. lumberjack / 应用内轮转和 logrotate 二选一，不要双轨。 双轨时两边各自保留 N 份，文件数 = 2N，且清理时机不同步，inode 消耗翻倍。我们最终保留应用内轮转（原子 rename + 自动删旧），节点侧 logrotate 只兜底（rotate 8 与之一致），并加了 find /var/log/app -name '*.log*' -mmin +120 -delete 的 10 分钟 cron 作为僵尸文件清道夫。
4. sizeLimit 撞墙时 containerd 不报错，是应用收到 ENOSPC。 容易误判成「磁盘坏了」。验证方法：kubectl exec 进 Pod dd if=/dev/zero of=/var/log/app/t bs=1M count=1，如果 ENOSPC 而 df -h 没满，就是 sizeLimit 或 inode 的问题。

五、结论与可复用清单

• [ ] 预算三条线分开算：字节（sizeLimit）、inode（rotate × 副本数）、节点系统盘总量（镜像 GC 管不了 emptyDir，见社区相关经验）。
• [ ] 文件数量必须有硬上限（rotate N），不允许「按时间无限滚」。
• [ ] 日志写失败 fail-open：计数 + 采样降级 + metrics 告警，绝不阻塞业务链路。
• [ ] 监控补 inode 维度：node_filesystem_files_free / node_filesystem_files，阈值 85% 预警。
• [ ] 双轨轮转二选一，配 10 分钟级 find -mmin +120 -delete 清僵尸文件。
• [ ] 验证命令：df -i、dd if=/dev/zero of=<dir>/t bs=1M count=1，两分钟定位是字节墙还是 inode 墙。

一句话：stdout 日志的预算线只有一条（节点磁盘），文件日志的预算线有三条（sizeLimit / inode / 系统盘），而且后两条在常规监控里不可见——配之前先算账，配之后先补监控。