节点磁盘打满后 Pod 被连环驱逐：kubelet 磁盘水位与容器日志清理的实战排查

作者苏知远

Kubernetes磁盘kubelet容器日志驱逐SRE

现象：一台 100GB 系统盘的节点，凌晨 40 分钟驱逐了 19 个 Pod

上个月凌晨 03:12，集群里一台 8C16G、100GB 系统盘的 worker 节点（Kubernetes 1.28.9，containerd 1.7.13）突然开始批量驱逐 Pod：03:12 起 40 分钟内，kubectl get events 里出现了 19 条 Evicted 事件，节点被打上 DiskPressure taint，调度器开始把该节点上的 Pod 迁移走。诡异的是，业务监控里没有任何一个应用的磁盘 I/O 飙升，df -h 显示 / 用量从 61% 在 3 小时内爬到 97%。

排查下来，磁盘空间的大头不是镜像，而是两个「看不见」的目录：/var/log/pods/ 下某个日志狂刷的容器写了 21GB 的 0.log，加上 emptyDir 里一个被当缓存用的临时目录 14GB——合计 35GB，占了增量空间的 80% 以上。镜像层本身只占 12GB，kubelet 的镜像 GC 根本没有触发。

根因：kubelet 的磁盘水位机制，很多人只知一半

kubelet 有两个独立的水位线（--eviction-hard 和 --image-gc-high-threshold / --image-gc-low-threshold），它们管的东西完全不同：

Eviction 水位（eviction-hard，默认 memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%）：一旦 nodefs.available（根文件系统可用空间）低于阈值，kubelet 把节点标记为 DiskPressure，并按优先级驱逐 Pod。注意它的判定对象是整个根文件系统——容器日志、emptyDir、镜像、系统日志全算在内。
镜像 GC 水位（默认 high 80% / low 75%）：只清理镜像层，且清理时按「最近使用时间」从旧到新删。我们的镜像只占 12%，从未触发。

反直觉的第一点：容器日志目录 /var/log/pods/ 和 /var/log/containers/ 完全不受镜像 GC 管辖。也就是说，一个每秒写 500KB 的日志容器，可以单枪匹马把节点写穿，而 kubelet 的「磁盘自保机制」对它毫无办法——它只能等整体水位超线后开始驱逐 Pod，此时业务已经受损。

反直觉的第二点：驱逐顺序不是按「谁占空间多」，而是按 QoS 优先级。BestEffort > Burstable > Guaranteed，同一 QoS 内再按「内存+磁盘」使用量从大到小。所以你的 Guaranteed 业务 Pod 是最后被驱逐的，但这不意味着它安全——节点驱逐会触发重调度，19 个 Pod 重建，P99 直接翻了 4 倍，持续了 25 分钟。

具体做法：三道防线，全部可复现

第一道：容器日志大小限制（最关键，一行配置）

在节点上给 containerd 加日志限制（/etc/containerd/config.toml）：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
  ...

更通用的做法是在 Pod 模板里加（对 docker/containerd 都生效的 kubelet 层参数不推荐，因为它是节点级一刀切）：

spec:
  containers:
  - name: app
    resources:
      limits:
        ephemeral-storage: 2Gi   # 注意：这只限容器可写层+stdout

或者用 containerd 的 max_container_log_line_size 配合 logrotate 兜底。我们最终方案是：所有生产 Pod 强制 ephemeral-storage limit（默认 2Gi），CI 环境放宽到 10Gi。

第二道：kubelet 驱逐阈值收紧 + 提前告警

# kubelet 启动参数（systemd override）
--eviction-hard=memory.available<500Mi,nodefs.available<15%,nodefs.inodesFree<10%
--eviction-minimum-reclaim=nodefs.available=5Gi

配套 Prometheus 告警（node_exporter + kubelet metrics）：

- alert: NodeDiskPressureSoon
  expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100) < 20
  for: 5m

阈值 20% 比驱逐线 15% 早 5 个百分点触发，给我们留了人工介入窗口。

第三道：emptyDir 显式声明大小

volumes:
- name: tmp
  emptyDir:
    sizeLimit: 4Gi

没写 sizeLimit 的 emptyDir 默认无上限，直接吃到根分区满。我们全集群扫了一遍，127 个 emptyDir 卷里 89 个没写 sizeLimit，全部补齐。

踩过的坑

ephemeral-storage limit 对 stdout 日志的生效时机：容器写日志超过 limit 后，kubelet 会驱逐整个 Pod，而不是把容器 OOMKill。我们一开始以为限流了日志，结果 Pod 反复重建，排查了 40 分钟才发现是驱逐。
/var/log/containers/ 的 symlink 结构：/var/log/containers/xxx.log 是指向 /var/log/pods/... 的软链，直接删软链不会释放空间，要删真实文件；用 truncate -s 0 比 rm 安全，因为文件句柄还开着。
镜像 GC 的 low threshold 不是「删到 75%」：它是「删到可用空间恢复到 low 线以下就停」，实际可能只删了 2GB 就停了。别指望它一次清干净。

结论与可复用清单

[ ] 所有生产 Pod 加 ephemeral-storage limit（默认 2Gi，有缓存需求的单独评估）
[ ] 所有 emptyDir 加 sizeLimit（建议 ≤ 4Gi）
[ ] kubelet eviction-hard 的 nodefs.available 收紧到 15%，eviction-minimum-reclaim 设 5Gi
[ ] Prometheus 告警：根分区可用 < 20% 持续 5 分钟
[ ] 每周巡检：du -sh /var/log/pods/* 排序，Top3 容器日志量 > 5GB 的必须加 limit
[ ] 记住：镜像 GC 管不了日志，驱逐不保护 Guaranteed Pod 的时间，只保护它的顺序

一句话总结：K8s 的磁盘自保机制只覆盖镜像层，容器日志和 emptyDir 是裸奔的，必须你自己上保险。

赞 6 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。