小天管理 发表于 9月30日 发表于 9月30日 使用 Ballast 文件解决 Docker 容器磁盘占满无法启动的问题 背景 在容器开发工作中,售卖算力容器是一个很常见的需求,不管是用 Docker 容器还是 K8s Pod 交付。 其中有一个问题是:我们提供给用户的容器默认是没有限制 / 目录的,虽然说这些都是临时文件,真正需要持久化的文件我们可以提供分布式存储,然后挂载到用户容器的某个目录。 一个简单而有效的方式是使用 XFS 文件系统配合 --storage-opt 参数就能限制用户容器的 / 目录,也可以说是限制用户容器的系统盘大小。 问题 但是当用户长期使用一个容器,比如在容器里进行模型训练,会导致系统盘空间越来越小,当系统盘空间已经非常接近我们设置的大小时,例如限制系统盘大小为 20Gi ,用户已经使用了 19.9999Gi ,这时候当用户 Stop 了容器(关机),再次 Restart/Start 容器(开机)时很可能会失败。 报错信息如下: Error response from daemon: mkdir /localData/docker/overlay2/7adae703b531d3e114cd171999e5502fe685e13835569b6f1d9fb31ab812773b/merged: disk quota exceeded 这好像没什么好的解决办法,因为造成问题的原因是用户把容器当成了虚机来用,一般情况下我们也不会持久化用户容器的临时文件。 但目前确实遇到了这个问题,所以和朋友一番讨论后,想出来了一个思路。 实现思路 前段时间研究了一下 Golang 控制 GC 频率的方法,其中使用的是 ballast ,就像下面代码中: 初始化了一个生命周期贯穿整个 Go 应用的超大 Slice ,保证 GC 在 10G 的一倍时才被触发。 详情参考这篇文章 性能优化 | Go Ballast 让内存控制更加丝滑 package main import "runtime" func main() { ballast := make([]byte, 10*1024*1024*1024) // 10G // do something runtime.KeepAlive(ballast) } 所以脑洞大开,我们能不能也用 ballast 的思想来为容器提供一个 ballast ,当容器磁盘不足时,我们手动减少这个 “压舱石” 的大小,这样就能能保证容器关机后,再次重启时,不会因为磁盘不足,导致失败了。 当然这样的操作是基于一个前提的,就是: 无论如何都不应该删除用户容器里的任何东西,即使是日志或者垃圾文件。 所以使用一个人畜无害的压舱石,可能是比较优雅的方式。 坏处也很明显,就是用户可以删除这块压舱石,并且用户 df -h 看到的空间是和实际购买的不一样。 具体实现 用户开通容器时 当用户开通一个容器,我们会限制用户容器的系统盘大小,比如说默认 20Gi 的空间,但是通过程序开通容器时,我们使用 --storage-opt size 限制时会把系统盘大小设置为 20Gi + 5Gi ,5Gi 的文件作为一个 ballast (压舱石)存在于用户的容器中。 当用户使用了 19.9Gi (实际情况下要比这个数字更接近 20Gi ) 的空间后,df -h 显示如下内容: $ df -h Filesystem Size Used / 25Gi 24.9Gi 用户关机时 重点在 Stop 时,如果说 Used 已经很接近 Size 了,那么我们就调整 ballast 的大小,保证用户容器正确启动。 举个例子,当 Used 已经为 24.9Gi ,限制的大小为 25Gi ,我们 Stop 时,把 ballast 的大小减小 0.5Gi, 保证用户容器正确启动。 源码地址 ballast-docker-container 如果对你有帮助,请给我一个 Star ⭐️
已推荐帖子
创建帐户或登录来提出意见
您需要成为会员才能提出意见
创建帐户
注册成为会员.只要几个简单步骤!
注册帐户登录
已经有帐户? 请在此处登录.
现在登录