Kubernetes成本优化实战：避免云资源浪费的5个最佳实践

我一度认为，持续上涨的Kubernetes账单只是上云的必然代价。每个月，它都在攀升，而人们总是归结于“Kubernetes就是这样的”。

事实并非如此。问题不在于Kubernetes本身，而在于我们使用它的方式。

当我不再将Kubernetes视为一个能自动解决所有问题的黑盒时，我开始在各个角落发现资源浪费：闲置的工作负载、容量过大的Pod、海量的日志记录以及并未实际生效的自动扩缩策略。经过数周的清理和调优，我们的云账单降低了40%。我们没有更换云供应商，也没有获得任何特殊折扣，仅仅是更好地利用了已有资源。

核心问题：普遍存在的过度配置

我们的配置堪称“YAML越多，问题越多”的典型：

• 数十个专为低流量微服务创建的命名空间。
• 启用了自动扩缩，但由于CPU请求设置过高，扩缩行为从未触发。
• 定时任务以每小时一次的频率运行，而实际业务只需每天执行一次。
• Fluentd流水线正在将数GB的调试日志写入高成本存储。

不恰当的使用让Kubernetes变得昂贵，而我们最初选择它正是因其宣称的简单与高效。

第一步：修正资源请求与限制

大多数团队的Pod要么处于“饥饿”状态，要么就是“营养过剩”。我们同时遇到了这两种情况。

我们对比了Pod的实际使用量与其声明的资源请求/限制，这通常可以通过云原生/IaaS领域的监控工具（如Prometheus指标）或Vertical Pod Autoscaler (VPA)的推荐模式来实现。

结果发现，大约70%的Pod请求的CPU和内存资源是其实际使用量的2-3倍。我们将这些限制下调至合理水平后，集群自动扩缩器（Cluster Autoscaler）几乎立即缩减了几个闲置节点。这直接带来了约15%的成本节约，且服务运行一切正常。

第二步：清理僵尸工作负载

接下来，我们开始搜寻那些早已被遗忘的“幽灵”工作负载。

使用以下命令可以快速列出所有Pod并按创建时间排序，有助于发现老旧资源：

kubectl get pods --all-namespaces --sort-by=.metadata.creationTimestamp

这次清查暴露了被遗忘的测试集群、已完成的批处理作业以及运行了数月之久的PR预览环境应用。我们删除了这些无用资源，并为预览环境引入了TTL（生存时间）控制器以实现自动清理。

成果：再次节省约10%的成本，彻底清除了这部分纯浪费。

第三步：采用更小规模的节点

我们曾认为运行大型节点（如32 vCPU以上）能降低管理开销。然而，Kubernetes的调度器并不总能将工作负载完美地打包进大型节点，常导致部分资源闲置，造成浪费。

我们将策略调整为使用更小的实例类型（例如，从 m6i.4xlarge 切换到 m6i.large），并让集群自动扩缩器根据总体需求来调整节点数量。这种混合使用较小节点的方式，显著提升了整体资源利用率。

成果：通过优化装箱密度，额外节省了约8%的成本。

第四步：确保自动扩缩真正生效

仅仅启用水平Pod自动扩缩器（HPA）并不意味着它在有效工作。我们的HPA CPU阈值设置得过高，导致扩缩从未触发。

我们重新设定了扩缩目标，基于第90百分位数（P90）的使用率指标而非随意猜测，并引入了基于自定义指标（如通过Prometheus Adapter提供的请求速率）的扩缩策略。调整后，在低流量时段，Pod能够顺利缩容，节点也随之减少，集群恢复了其应有的弹性。

成果：在自动扩缩生效后，进一步节约了5-7%的成本。

第五步：实施日志与存储“节食计划”

这是最具挑战性的一步。我们发现在EBS卷和日志存储上的开销，甚至超过了计算资源本身。

审计发现，大量的调试跟踪信息、系统日志都被存储在高性能的块存储上。我们采取了以下措施：

1. 将历史日志迁移至S3 Glacier等低成本归档存储。
2. 将非关键日志的保留期从1年缩短至7天。
3. 在生产环境中彻底关闭调试级别日志的输出。

成果：通过优化存储策略，节省了约6%的成本。

关键结论

Kubernetes本身并不昂贵，成本高昂的往往是运行不善的Kubernetes集群。我们很容易将问题归咎于云服务商，但真相通常是资源利用率的低下。

完成这次优化后，我们的集群变得更小、更快、更易于维护，成本也回归到了合理水平。现在，我会定期检查资源使用情况，积极减少资源占用，并审慎评估每一个新增工作负载的必要性。

如果你也在为Kubernetes成本困扰，请不要轻易放弃这个平台。从检查资源请求、清理无用负载、调整节点规模、优化自动扩缩配置开始，并停止记录一切不必要的日志。你很可能会发现，账单中可观的一部分浪费，源于自身的配置。