Kubernetes 把应用从单机部署带入了动态调度和弹性伸缩，但账单也因此更难解释：一个团队的 Pod 可能跨多个节点，节点还会被多个命名空间共享。FinOps 的目标不是简单地“少买机器”，而是把云账单分摊到工作负载，再用可观测数据调整资源和容量。
先让成本与工作负载对应起来
成本治理的起点是可见性。建议先为 Namespace、Deployment、Job 和团队建立稳定的标签，例如 team、service、environment、cost-center。没有归属的 Pod、共享节点、存储卷、负载均衡器和公网流量，都应单独列为“未分摊成本”，否则团队报表会给出过于乐观的结论。
Kubernetes 的资源指标适合回答“Pod 用了多少 CPU 和内存”，但不等于云账单。长期分析通常需要把节点、持久化存储、网络出口以及云厂商账单导入成本模型。OpenCost 可以按 Namespace、工作负载和节点分配成本；接入后仍应核对云厂商计费项和费率，尤其是跨可用区流量、磁盘和托管控制面是否被纳入。
监控层可以用 Metrics Server 支撑自动扩缩容，用 Prometheus 等时序系统保存历史使用数据。报表至少同时展示以下维度：
requests与实际使用量的差距；- 节点和工作负载的利用率；
- 持久化存储、负载均衡和网络费用；
- 每个团队的成本、业务请求量和错误预算。
用 requests 和 limits 控制资源浪费
Kubernetes 调度器主要依据 Pod 的 resources.requests 判断节点是否有足够容量，limits 则限制容器运行时的资源上限。两者职责不同，不能把一个数值同时当成容量规划和峰值保护：
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
requests 过高会让节点提前“排满”，即使实际 CPU 使用量很低也无法继续调度；过低则可能在高峰期争抢资源。可以根据一段完整业务周期的历史数据和压测结果设置初值，再观察延迟、重启和驱逐情况逐步调整。CPU 超过 limit 时通常会被节流，内存超过 limit 可能触发 OOM，因而不能只为提高利用率而盲目下调内存配置。
对没有明确资源配置的命名空间，可用 LimitRange 提供默认值，用 ResourceQuota 限制总请求量和对象数量。VPA 的推荐模式适合发现长期偏大的请求；自动修改请求可能导致 Pod 重建，应先在无状态服务或测试环境验证。把“请求值、实际用量、SLO 结果”放在同一张报表中，比只看 CPU 百分比更可靠。
让副本和节点随业务变化
扩缩容要区分三个层次：
- HPA 根据 CPU、内存或业务指标调整 Deployment 的副本数；
- Cluster Autoscaler 在 Pod 无法调度或节点长期空闲时调整节点池规模；
- VPA 根据历史用量给出或应用单个 Pod 的资源建议。
三者同时启用时要划分职责，避免 HPA 增加副本、VPA 又提高每个副本请求，最终造成不必要的节点扩容。HPA 的目标指标也不应只选 CPU；队列长度、请求延迟和并发数往往更贴近业务 SLO。缩容则要配合 PodDisruptionBudget、优雅终止和连接排空，避免节省成本时引入故障。
按可靠性选择节点和计费方式
可以把节点池按工作负载隔离，并用 taint、toleration、亲和性和拓扑分布约束调度：
- 有状态数据库、核心交易和需要稳定容量的服务使用按需或承诺型容量；
- 可重试的批处理、CI 任务和无状态计算可以使用 Spot/抢占式实例，但必须处理回收通知、重试和数据持久化；
- GPU 节点单独建池，避免普通服务占用昂贵资源。
承诺型折扣或预留容量只覆盖经过持续观测的基础负载，弹性部分保留按需容量。不要把厂商宣传的固定折扣直接当作预算依据，实际价格、区域和实例家族都会改变成本结果。
多租户治理要有责任人
共享集群需要把技术约束和组织责任结合起来。每个 Namespace 至少应配置资源配额、默认请求/限制、负责人和成本中心；CI/CD 在部署前校验资源字段，策略引擎拦截没有归属标签或超出配额的工作负载。成本告警可以按团队预算、单次发布增量和异常利用率触发，并把通知送到真正能处理问题的人。
一条可落地的实施路线
- 统一标签和命名，盘点节点、存储、网络及未分摊费用。
- 用 OpenCost 或等效工具生成 Namespace/工作负载成本报表，并与云账单对账。
- 依据历史用量和 SLO 调整
requests，用 VPA 推荐结果辅助复核。 - 为关键服务配置 HPA，为节点池配置 Cluster Autoscaler，补齐中断和缩容保护。
- 最后再引入 Spot、承诺型容量和自动化策略，把节省结果纳入持续评审。
评估效果时不要只看总账单，还要同时关注单位请求成本、节点利用率、Pending Pod 时长、发布成功率和延迟。这样才能确认节省来自资源效率提升，而不是把风险转移给业务。
Kubernetes FinOps 的核心是把“谁使用了什么资源、为此付出多少、是否满足 SLO”连接起来。先建立可信的成本与使用数据，再做资源治理和自动化扩缩容，成本优化才会变成可重复的工程流程。