Pod 的健康检查耗尽 /run 存储空间，差点卷铺盖走人
内容提要
JuiceFS用户使用nvidia-container-runtime需关注Dragonfly安装问题和磁盘空间不足导致的告警。清空相关文件解决问题。讨论了log.json日志增长问题和解决方案，包括清理超过100M的log.json文件和修改nvidia-container-runtime的日志级别。
延伸解读
健康检查失败与日志膨胀的关联
文章通过构造测试负载发现，当Pod的健康检查命令执行错误时，每次探测都会在log.json中记录一条错误日志。若探针每秒执行一次，两个月即可积累数GB日志。这提示运维人员，频繁失败的健康检查不仅是业务问题，还可能成为磁盘空间的隐形杀手，需定期审查探针配置的合理性。
nvidia-container-runtime的日志级别调整
除了清理日志文件，文章建议修改nvidia-container-runtime的配置文件，将log-level从info改为error，以减少info级别日志的输出。这一措施能有效降低日志产生速率，但需注意修改后可能丢失部分调试信息，适合在稳定运行环境中采用。
Containerd state目录迁移的考量
文章提到可将Containerd的state目录从/run/containerd迁移到/data/containerd，并将/data挂载到大容量磁盘。这能从根本上缓解/run分区空间不足的问题，但迁移前需评估对现有容器运行状态的影响，并确保新目录的权限和挂载配置正确。
Q&A
为什么 Pod 健康检查会导致 /run 存储空间被耗尽？
健康检查探针命令执行错误时，每次探测失败都会在 /run/containerd/io.containerd.runtime.v2.task/moby/<容器ID>/log.json 中写入错误日志。如果探针每秒执行一次且持续失败，log.json 文件会快速增大，最终占满 /run 分区。
如何快速定位是哪个文件占满了 /run？
使用 df -h 查看 /run 使用率，然后进入 /run/containerd/io.containerd.runtime.v2.task/moby 目录，用 ls -alh 或 du 查找大文件，通常会发现多个数GB的 log.json 文件。
log.json 文件增长与 nvidia-container-runtime 有什么关系？
nvidia-container-runtime 默认以 info 级别记录日志，每次容器运行时都会输出配置信息到 log.json。如果健康检查频繁失败，这些 info 日志会不断累积，加速 log.json 增长。
如何清理已经过大的 log.json 文件？
可以使用 opscli 工具，执行命令查看超过 100M 的 log.json 文件，然后加上 --clear 参数直接清理。例如：opscli task -f ~/.ops/task/clear-biglog.yaml --logpath /run/containerd/io.containerd.runtime.v2.task/moby/ --logname "log.json" --size 100M -i ~/.kube/config --all --clear。
如何修改 nvidia-container-runtime 的日志级别来减少日志输出？
编辑 /etc/nvidia-container-runtime/config.toml，将 [nvidia-container-runtime] 下的 log-level = "info" 改为 log-level = "error"，这样可以避免输出 info 级别的配置日志。
除了清理日志和调整日志级别，还有什么方法避免 /run 空间不足？
可以修改 Containerd 的 state 目录，将 /etc/containerd/config.toml 中的 state = "/run/containerd" 改为 state = "/data/containerd"，并将 /data 挂载到更大的磁盘上。
