Docker 容器成本优化有哪些实用方法？

Docker 容器成本优化不能只盯着“少跑几个容器”。真正花钱的地方通常藏在镜像存储、节点空转、日志膨胀、网络出口、过度预留和不合理扩缩容里。比较稳妥的做法是先看账单和监控，再决定优化顺序。

先把镜像做小

镜像越大，构建、拉取、存储和发布都会变慢，也会增加镜像仓库费用。常见做法有三类：

• 使用更轻的基础镜像，例如 alpine、slim 或 distroless；
• 用多阶段构建，只把运行时真正需要的二进制、依赖和配置复制到最终镜像；
• 清理构建缓存、包管理器缓存、临时文件，避免把测试文件、源码和文档一起打进生产镜像。

不过轻量镜像不是无脑选择。比如 Alpine 使用 musl libc，某些依赖在兼容性和性能上可能踩坑。更稳的做法是对核心服务做一次启动耗时、镜像体积和运行稳定性的对比，再决定是否切换。

管好镜像仓库生命周期

很多团队只优化 Dockerfile，却忘了 registry 也在持续花钱。每次 CI/CD 都推一个新 tag，半年后镜像仓库里可能堆着几千个历史版本。

可以设置镜像生命周期策略：

• 生产镜像保留最近 N 个稳定版本；
• 开发、测试、PR 临时镜像设置较短过期时间；
• 未被部署引用的镜像定期清理；
• 大镜像单独告警，避免某次构建把体积突然拉高。

如果使用 Harbor、ECR、GCR、ACR 等仓库，通常都支持保留规则或自动清理策略。注意不要只按 tag 删除，最好确认当前集群、回滚版本和灾备流程不会依赖这些镜像。

正确设置 requests 和 limits

在 Kubernetes 里，成本浪费最常见的来源之一是资源申请不准。requests 决定调度时预留多少资源，limits 决定容器最多能用多少资源。

如果 requests 设得太高，节点看起来已经满了，但真实 CPU 使用率可能只有 20%。这会导致集群不断扩容，钱花在空转节点上。反过来，如果设得太低，Pod 容易被挤在一起，出现 CPU 抢占、内存 OOM 或延迟抖动。

建议做法是：

• 根据最近 7 到 30 天的真实监控数据设置 requests；
• CPU requests 可以相对保守，CPU limits 不一定必须设置得很死；
• 内存 limit 要更谨慎，因为超过后可能直接 OOMKilled；
• 对不同服务分层，核心链路比离线任务留更多余量。

有条件的话，可以配合 VPA 或成本分析工具给出建议值，但不要让它在生产环境里随意自动改核心服务配置。

自动扩缩容要设好上下限

HPA、KEDA、Cluster Autoscaler 可以让容器数量和节点数量跟随负载变化，但配置不好也会浪费钱。

关键是三个参数：最小副本数、最大副本数和扩缩容指标。最小副本数太高，低峰期也会空跑；太低，流量上来时冷启动又可能扛不住。最大副本数太高，异常流量或错误指标可能把成本瞬间拉爆。

比较实用的做法是：

• 核心在线服务保留合理的最低副本数；
• 后台任务、消费型服务按队列长度或事件数扩缩容；
• 设置最大副本数，避免异常流量导致无限扩容；
• 配置缩容冷却时间，防止频繁扩缩容造成抖动。

扩缩容不是为了“永远省钱”，而是在低峰少花钱、高峰不崩。

提高节点装箱率

容器成本优化还有一个很容易被忽略的词：bin packing，也就是把 Pod 更合理地装进节点里。

如果每个服务的 requests 都偏大，或者节点规格选得不合适，就会出现很多碎片资源：这个节点还剩一点 CPU，那个节点还剩一点内存，但都不足以再调度一个 Pod。结果就是集群明明总体资源没用完，却还要继续加节点。

可以从这些方向优化：

• 选择更匹配业务负载的节点规格；
• 把 CPU 密集型和内存密集型服务合理混部；
• 使用 node affinity、taints、tolerations 控制关键服务位置；
• 对离线任务使用低优先级，避免抢占在线服务资源；
• 定期查看节点利用率和不可调度 Pod 的原因。

Kubernetes 的调度不是魔法，它只能根据你填的 requests 做判断，所以前面的资源设置会直接影响装箱率。

使用 Spot 或抢占式实例要留后手

Spot、Preemptible、竞价实例通常能明显降低节点成本，适合跑可重试、可中断、无状态或离线计算任务。

但它们的风险也很明确：实例可能随时被回收。如果把核心数据库、关键在线服务、长时间不可重试任务放上去，省下来的钱可能不够一次故障损失。

更稳的使用方式是：

• 在线核心服务优先跑在按量或预留实例上；
• 批处理、CI、异步消费、数据处理放到 Spot 节点池；
• 配置 PodDisruptionBudget，避免一次回收影响太多副本；
• 应用层支持重试、断点续跑和幂等处理；
• 保留一定按量节点兜底。

Spot 是降成本工具，不是免费午餐。

做 rightsizing，不要长期用大规格

很多容器一开始为了省事会给很大的 CPU、内存和节点规格，后面业务稳定了却没人再回头看。这类“历史遗留余量”会持续烧钱。

Rightsizing 的思路是把实际使用量、峰值、SLO 和资源配置放在一起看：

• 长期 CPU 使用率很低的服务，可以下调 requests；
• 内存稳定且峰值清晰的服务，可以收紧 limit；
• 节点长期低利用率，可以换更小规格或减少节点数；
• 有明显周期波动的业务，用定时扩缩容比固定高配更划算。

不要只看平均值。平均 CPU 10% 的服务，可能每天有 10 分钟冲到 90%。优化前要看 P95、P99 和业务高峰窗口。

控制日志、存储和网络出口费用

容器本身不贵，旁边的配套资源经常更贵。

日志是典型例子。默认把 debug 日志全量打到集中式日志系统，时间一长，采集、索引和存储都会变成大头。可以按环境和服务级别调整日志等级，给高频日志做采样，设置合理保留周期。

存储也类似。共享数据卷可以避免重复存储，但要注意容量、快照、备份和 IOPS 是否过度配置。临时文件、缓存目录、构建产物最好有明确清理策略。

网络出口费用更容易被低估。跨可用区、跨地域、出公网传输都可能收费。如果服务频繁拉取大镜像、跨区访问对象存储，账单会很难看。可以通过就近部署、镜像缓存、私有网络访问和减少跨区调用来控制成本。

清理资源要安全

docker system prune、清理未使用镜像和删除停止容器确实能释放空间，但生产环境不能随手执行。

更安全的做法是：

bash
docker system df
docker image prune -a --filter "until=168h"
docker container prune --filter "until=168h"

先查看占用，再按时间窗口清理。不要在不了解依赖的情况下删除 volume，因为数据卷里可能有业务数据。Kubernetes 环境下，也要区分节点本地缓存、PVC、镜像缓存和日志文件，清理策略不能一刀切。

用监控和成本分摊定位问题

没有成本归因，优化只能靠猜。建议至少按 namespace、应用、团队、环境打标签，把 CPU、内存、存储、日志、网络和节点费用分摊到具体业务。

常见观察指标包括：

• Pod 的 CPU、内存 requests 与真实使用量对比；
• 节点利用率和空闲资源；
• 镜像体积和拉取频率；
• 日志写入量、索引量和保留周期；
• 网络出口流量和跨区流量；
• 每个 namespace 或团队的单位成本。

这样才能知道该先优化镜像、节点、日志，还是网络。很多时候，最值得动手的不是技术上最酷的部分，而是账单里增长最快的那一项。

Docker 和 Kubernetes 场景有什么不同

如果只是单机 Docker，重点通常是镜像体积、容器数量、资源限制、磁盘清理和日志轮转。

如果是 Kubernetes，成本优化会多出调度和集群层面的内容：requests/limits、HPA、VPA、Cluster Autoscaler、节点池、Pod 分布、PDB、namespace 成本分摊、Spot 节点池等都要一起看。

所以 Docker 容器成本优化可以按这个顺序推进：先减小镜像和仓库存储，再校准资源申请，然后优化扩缩容和节点装箱率，最后处理日志、存储、网络出口和成本归因。这样改动风险比较低，也更容易看到真实账单变化。