Kubernetes 集群的账单通常不是被某一个“大服务”突然推高，而是被许多小偏差长期累积：Pod 申请量高于真实用量、空闲节点无法回收、测试环境常驻、多团队共用资源却没有成本归属。要解决这些问题，关键不是先砍预算，而是先建立一条从工作负载到云资源的可观测链路。
先看懂成本是怎样形成的
集群成本至少包含计算节点、持久化存储、负载均衡、公网流量和托管服务费用。云账单能告诉你买了什么，却未必能说明哪个 Namespace、Deployment 或团队消耗了这些资源。
因此，第一步应统一资源归属标签，例如：
metadata:
labels:
team: payments
environment: production
cost-center: cc-1024
标签必须进入发布模板和准入规则，不能依赖上线后人工补齐。随后再用 OpenCost 一类工具，把节点、存储和云费用分摊到 Namespace、工作负载或标签维度。OpenCost 官方将自身定位为面向 Kubernetes 的厂商中立开源成本计量与分配项目，可用于实时监控、showback 和 chargeback。
有了成本归属后，建议同时观察三组指标：
- 申请量：Pod 的 CPU、内存 requests；
- 实际量：一段完整业务周期内的使用分布，而不是某个瞬时值；
- 容量结果：节点可分配资源、不可调度 Pod、空闲节点和扩缩容事件。
只看实际使用率容易忽略调度约束，只看 requests 又会把配置误差当成真实需求。两者必须结合。
requests 与 limits 应该怎样校准
Kubernetes 官方文档明确说明：调度器使用 requests 决定 Pod 放在哪个节点；kubelet 负责执行 limits。也就是说，requests 配得过高，即使容器实际很空闲，调度器仍会把那部分容量视为已占用。
调整时不要直接用平均值覆盖配置。更稳妥的方法是：
- 选取能覆盖工作日、周末、发布和流量高峰的观察窗口；
- 分别查看 CPU 与内存的分位值、峰值持续时间和异常点；
- 先生成建议值，在预发布或少量实例上验证；
- 观察延迟、错误率、重启、OOM 和节流情况；
- 确认稳定后再逐步扩大范围。
CPU 和内存也不能用同一逻辑处理。CPU limit 触发时通常表现为节流，可能增加请求延迟；内存超过 limit 则可能导致容器被终止。因此，低延迟服务是否设置严格 CPU limit，需要结合服务等级目标和运行时特征评估，不能照搬统一模板。
对于没有资源配置的工作负载，可以通过 LimitRange 提供默认值，通过 ResourceQuota 控制 Namespace 总量。但默认值只是安全起点，不是最终容量结论。
把工作负载伸缩与节点伸缩配成一套
HPA 会根据资源指标或自定义指标调整 Deployment、StatefulSet 等工作负载的副本数。节点自动伸缩则在现有节点无法容纳 Pod 时增加节点，并在条件允许时整合或回收容量。两者职责不同：
- HPA 解决“需要多少个 Pod”；
- 节点自动伸缩解决“需要多少台、什么规格的节点”。
如果 requests 严重虚高，HPA 增加副本后可能快速制造大量不可调度 Pod，节点伸缩器又会据此扩容，最终把配置误差放大成真实账单。Kubernetes 官方也说明，节点伸缩主要依据 Pod 调度约束和 requests，并不直接依据 Pod 启动后的真实使用量。
生产环境可按以下顺序建设：
- 先保证关键工作负载有合理 requests；
- 为 HPA 选择能反映业务压力的指标，必要时加入请求率、队列长度或延迟；
- 为节点池定义规格、可用区、最小与最大容量；
- 配置 PodDisruptionBudget、优雅终止和健康检查；
- 通过故障演练验证扩容速度、缩容驱逐和容量不足时的表现。
VPA 可以提供资源建议或调整 requests，但自动更新可能引发 Pod 重建。对有状态或对重启敏感的服务，先使用推荐模式观察，再决定是否自动应用。
节点池与计费方式怎么选
稳定基础负载与波动负载应分开规划。持续运行、容量可预测的部分适合使用长期承诺类计费；短时峰值继续保留按量弹性。不要用峰值购买全部长期容量，也不要把稳定底座全部交给临时资源。
可中断实例适合能够重试、容忍驱逐的批处理、测试任务和部分无状态服务。核心交易、单副本服务、有状态数据库或无法快速恢复的任务，不应仅因为单价较低就迁入可中断节点池。
节点池至少应按以下维度拆分：
- 稳定生产负载与弹性负载；
- 通用计算、内存优化和 GPU 等不同资源形态；
- 可中断与不可中断容量；
- 有特殊合规、网络或可用区要求的工作负载。
通过 node affinity、taints 和 tolerations 控制去向，同时避免把规则写得过死，否则会降低装箱率并增加不可调度风险。
建立可持续的 FinOps 闭环
有效的 Kubernetes 成本优化应当是周期性流程，而不是一次性清理：
- 每周查看成本异常、空闲资源和 requests 偏差；
- 每月复核团队归属、预算与长期容量承诺；
- 每次发布后对比单位请求、单位任务或单位训练作业的成本变化；
- 所有自动优化建议先经过风险分级，高风险变更保留审批和回滚；
- 将延迟、可用性和恢复能力与成本指标放在同一张评审表中。
一个实用的推进顺序是“可见—校准—伸缩—治理”：先建立成本分摊，再校准工作负载资源，随后接入自动伸缩，最后用策略和组织责任把效果固定下来。
上线前检查清单
- 工作负载具备统一的团队、环境和成本中心标签；
- 账单能够分摊到 Namespace 或工作负载；
- requests 来自完整业务周期的数据，而非单次峰值或平均值；
- HPA 与节点伸缩的指标、边界和冷却策略经过压测；
- 缩容不会破坏副本、状态数据或服务等级目标；
- 可中断实例上的任务能够重试和恢复；
- 自动建议具备审计记录、灰度验证与回滚路径；
- 成本下降没有以延迟、稳定性或容灾能力为代价。
资料核对依据：