K8s ephemeral-storage limit 怎么设才既不"误杀"业务 Pod 又能真正防住节点磁盘打满？

背景 我维护一个 8 节点（32C128G，K8s 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，上面混跑 Java 微服务、Go 网关和一个 Flink 流计算作业。最近两次节点磁盘（/var/lib/containerd + /var/log）被打满，触发 kubelet 驱逐，连带杀掉了不相关的业务 Pod。

现象

• Java 服务日志量大（约 200MB/h），走 stdout → containerd log-driver，落在 /var/log/containers/；
• Go 网关用 os.TempDir() 写临时 TLS 证书，单次 50–200MB；
• Flink 作业 checkpoint 目录在容器 /tmp 下，单次可达 2GB+，IO 突发明显；
• 目前所有 Pod 统一设了 resources.limits.ephemeral-storage: 10Gi，结果 Flink 被驱逐过两次，而真正持续吃磁盘的 Java 日志 Pod 反而没被限制住（因为日志走 stdout → containerd，不经过容器的 ephemeral-storage cgroup）。

已尝试的排查

1. 把 Java 日志改为文件输出 + logrotate，但 containerd 的 log-driver 仍在 /var/log/containers/ 下占空间，且 kubelog 没有针对单 Pod 的清理策略；
2. 给 Flink 单独把 ephemeral-storage limit 调到 8Gi，但 checkpoint 写入期间 IO 峰值仍短暂超限，被 kubelet 驱逐；
3. 考虑用 emptyDir + sizeLimit 替代 /tmp，但 K8s 1.28 文档里 emptyDir sizeLimit 的驱逐行为描述得很模糊（是硬杀还是先 SIGTERM？阈值是 usage 还是 usage+reserved？）；
4. 看了 cAdvisor 的 container_fs_usage_bytes，发现它统计的"container fs"并不包含 containerd 日志目录，所以监控侧也看不到真实磁盘压力。

期望得到的答案形态

• ephemeral-storage 到底覆盖了哪些路径（stdout 日志算不算？emptyDir 算不算？/etc、/usr 等镜像层算不算？）；
• 不同 IO 模式（持续写 vs 突发写）下 request/limit 的合理设置方法或经验公式；
• 有没有比"设 limit + 驱逐"更优雅的磁盘保护方案（比如 cgroup v2 的 io.max 限速、节点级 disk-pressure taint 的阈值调优、containerd log rotation 配置）？
• 如果混跑不同 IO 模式的工作负载，ephemeral-storage 的 QoS 分级（Guaranteed / Burstable / BestEffort）有没有实际意义？