容器化并不会让磁盘容量自动得到管理。日志、旧镜像、临时文件和上传数据都可能持续增长，最终影响应用或数据库。磁盘治理应先识别用途与保留责任，再安排清理。
按数据类型统计增长
区分容器日志、镜像层、构建缓存、持久化卷和业务文件。不要看到某个目录很大就直接删除，它可能承担恢复或客户数据存储。容量告警应结合剩余空间与增长速度，而非只设一个固定百分比。
为日志设置可追溯的保留规则
约定采集、轮转和集中存储方式，确认故障时仍能查询需要的时间范围。只把日志文件搬到另一个目录，不能解决无界增长。应用也应避免持续输出大请求体或高频重复错误。
清理镜像前检查恢复需求
正在使用和回滚窗口内的镜像必须可获取。自动清理流程应能区分可再生缓存与必须保留的数据，不使用覆盖所有卷的通用清理命令处理生产问题。
验收容量逼近阈值时的行为
在受控环境验证告警、日志轮转与清理记录，检查清理后应用和回滚产物仍然可用。运行手册应给出核实步骤和责任人。
常见问题：增加磁盘就能结束这个问题吗？
扩容可以争取时间，但若没有增长与保留规则，容量压力通常还会再次出现。
技术参考：Docker：镜像构建实践。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。