Kubecost 详解：真正影响账单的 Kubernetes FinOps

Kubecost 是构建在 OpenCost 之上的 Kubernetes 成本分摊与优化平台，它把集群遥测和云厂商的账单数据结合起来，把支出归属到命名空间、工作负载和团队这些真正的负责人头上。当集群账单需要的是负责人而不是估算时，就该部署它；但它的数字要等云账单对账之后才可信，而且只有配上运营节奏，这些数字才会变成真正的节省。

大多数平台团队对 Kubernetes 成本并不陌生。每月的云账单到了，财务问为什么涨了，工程团队只能回一句“工作负载更多了”。账单显示的内容和平台团队能解释的内容之间的这种差距，正是 FinOps 要解决的问题，目的是优化运营成本。真正的问题在于：为此你是不是非用一个商业平台不可。对大多数团队来说，答案是不必。OpenCost 和 Kubecost 可以给平台团队提供所需的可见性，前提是把工具和运营节奏搭配起来用。

压力是真的

Kubernetes 成本核算早就不只是单一集群、单一云的事了。如今大多数团队管理的是一组组集群，常常横跨多家云厂商，有时还会把本地控制平面和托管服务混在一起。容器在节点之间迁移，节点在可用区之间迁移，同一个工作负载为了满足延迟或合规要求可能在多个区域里运行，这让成本归属变得更难。

业界数据已经讲了好几年的同一个故事。2021 年的 CNCF FinOps 调查发现，大多数团队无法可靠地度量自己的 Kubernetes 花费，主要问题是过度预留和缺乏责任归属。2025 年还是同一个故事：一份基于 AWS、GCP 和 Azure 上 2,100 多家组织的真实集群数据的 Cast AI 2025 Kubernetes Cost Benchmark 显示，CPU 平均利用率为 10%，内存利用率为 23%。这些数字来自生产环境的遥测，而不是问卷回答。四年过去问题没变，如果说有什么不同，只是随着集群规模扩大变得更明显了。

真正的问题不是 Kubernetes 太贵，而是大多数团队对自己花在哪里看得不够清楚。

Kubecost 到底是什么？

Kubecost 是一个 Kubernetes 平台，负责成本分摊、优化和治理。2024 年被 IBM 收购之后，Kubecost 提供开源版和企业版两个形态。它的核心建立在 OpenCost 之上，以集群内的代理栈方式运行，包含若干微服务：数据收集器、云成本摄取器、预测服务、按节点的网络成本 DaemonSet，以及一个 ClickHouse 驱动的快速聚合器。通过把 Kubernetes 遥测与云厂商的账单数据结合起来，Kubecost 提供细致的成本分摊视图；一旦云账单集成完成配置并完成对账，精度还会进一步提升。

平台围绕三大支柱构建：

• 成本分摊 按命名空间、标签、服务、工作负载，或者 Collection 把开销聚合起来。Kubecost v3 新增了分组概念，把 Kubernetes 侧和外部云侧的成本归并为一个去重后的单元。成本追踪覆盖 CPU、内存、持久卷、GPU 和网络流量。
• 优化建议 基于真实使用量给出合理的资源请求，推荐更便宜的节点类型，并允许团队配置分位数式的控制，而不是接受一个一刀切的默认值。建议可以归档作历史参考，也可以导出为 CSV 或 PDF。
• 告警与治理 以可配置的预算动作、定时报表、Slack/邮件通知的形式提供。告警直接挂在它所对应的预算旁边，而不是单独的告警子系统。

一次 Kubecost 安装的流程

成本数据的采集从集群内部开始。启动时，FinOps agent 会在 Kubernetes API 上为价格 ConfigMap 设置一个 watch，这样任何自定义的价格规则不重启就能生效。它还会逐节点解析节点价格(在云厂商价格不可用时回退到一个计算值)。然后它会从每一个 Network Costs DaemonSet pod 上收集指标，创建一份新的二进制快照，如果配置好了，就把它写到外部存储，比如 Azure Blob Storage 或 AWS S3。

Network Costs DaemonSet 通过 netlink socket 订阅内核的 conntrack 表，按方向解析每条流的字节数和包数计数器，并通过 Kubernetes API watch 在内存中维护一份 pod、节点、服务和 endpoint 状态的映射。它用这份映射把观察到的连接关联到具体的工作负载上。

在这些代理把内部快照送到共享存储的同时，Cloud Cost Ingestor 负责管理外部的财务数据。它按计划运行，连接云厂商的账单导出，拉取每日 CSV，并补齐历史数据。因为云厂商发布账单数据有几小时的延迟，Kubecost 会等一小段时间再把集群数据与云账单对账。这意味着最近一两天的成本数据只是估算，更老的数据则会完全对账(前提是云账单集成在正常工作)。

Aggregator 是主引擎，使用内嵌的 ClickHouse 数据库。在多集群部署里，它会汇聚多个代理集群的快照。它会检查多个 ConfigMap 取配置，如果都没有就回退到默认值。它摄取代理快照，以及在配置好的情况下摄取外部账单 CSV，然后将这些数据送入多阶段 SQL 流水线，完成对账并去重重叠成本，最终产出供其他微服务消费的成本表。Aggregator 还通过为 ClickHouse 设置按表、按分辨率的 TTL 来管理数据保留，所以细粒度窗口会在几天内过期，而汇总会保留数周到数月。

最后，Forecasting Service 作为预测性成本监控工具，使用这些数据生成成本预测。与此同时，Cluster Controller 利用 Aggregator 的优化洞察去执行动作，比如把合理化建议直接应用到集群里。

先把成本分摊到真正的负责人头上

Kubecost 会把节点成本分摊到该节点上运行的 pod 上，通常以资源请求加权，然后按命名空间、标签、服务、工作负载或 Collection 汇总结果，覆盖 CPU、内存、PV、GPU 和网络。

让这套办法真正生效的，不只是技术上的搭建，更是组织上的清晰。每个命名空间都应该对应一个真实的负责人：一个团队、一款产品、或者一个部门。这层映射一旦到位，分摊视图就能直接显示每笔成本归哪个团队，不再需要靠一张电子表格去拼。已经使用 team、cost-center、product 这类标签的团队，可以为同样的目的复用它们，而 Collections 让基于标签的视图更好用。

标签会随时间变化，命名空间会变多，迟早有人会往 default 里部署。每周回顾一下没打标签的那一桶，能让数据保持准确、可用。

让请求与实际使用对齐

这是动账单最有力的杠杆。开发者经常出于保险心态把 CPU 和内存请求设得很高，然后再也不去回头看，而请求和实际使用之间的差距就直接体现在账单上。前面引用过的“CPU 10% / 内存 23%”基准，在财务向你要个数字时是一个有说服力的依据。

一种能稳定找到节省空间的做法是：把每个工作负载几个星期内 请求 vs 实际 的 CPU 和内存画出来，然后逐个把每个工作负载的请求往实际使用量上靠。一个真实案例来自某个服务网格部署：proxy sidecar 每个被设成 100 毫核。纸面上节点能容纳大约 200 个 pod，但调度器在大约 90 个 pod 的时候就把可分配 CPU 用完了，因为每个 pod 在自己的请求之外还顶着一份 100 毫核的 sidecar 请求。做完一轮请求合理化之后，每节点的 pod 密度翻了三倍，应用没改动、节点池也没改动。

Kubecost 3.0 让这条回路更紧。Container Request Sizing Insights 会把使用量可视化直接放进 UI，建议可以归档，CSV/PDF 导出带标签，分位数式的控制让你能为可预测的服务设置更紧的建议百分位，为有突发的工作负载设置更松的百分位。企业层加上了一个 Automated Container Request Sizing UI，可跨集群运行，带自定义画像、暂停控制、审计历史，以及推荐节省额与实际节省额的对比；开源层在 EKS 主集群上最多可享受 250 核的免费额度。

在生产中，基于分位数的建议策略通常是最有效的做法。

• 把 CPU 请求设为过去一周或一个月内实际 CPU 使用量的 90 分位，然后加上一个安全余量。Kubernetes VPA 的默认 CPU 余量大约是 15%。因为 CPU 是分时共享的，只要有空余，内核就会让突发的工作负载用上额外容量。为罕见的尖峰再加更多 padding，通常只是单纯抬高了请求，收益不大。
• 把内存请求设为峰值使用量的一个较高分位，然后加上一个安全余量。内存不是分时共享的，所以越过上限可能直接导致 OOM kill，而不是优雅降级。目标定在峰值的 90 分位左右，然后加上余量。VPA 默认的内存余量大约是 20%。

这些设置决定了 QoS 类。只有当 pod 中所有容器的 CPU 和内存请求都等于其上限时，这个 pod 才被视为 Guaranteed。只要有一个容器不满足，整个 pod 就被当作 Burstable；如果所有容器都没设请求或上限，则被当作 BestEffort。这种设置对大多数工作负载是合适的。把完全的 Guaranteed 类留给延迟 SLA 极严苛的关键工作负载，让它们的 CPU 和内存请求等于上限。在那些场景下，你也许会浪费一些余量，但能换来最好的驱逐保护，以及必要时的独占 CPU 绑定。

如果你想在自动化任何步骤之前再加一道反馈，可以让 VPA 在仅建议模式下跑几个星期，或者使用开源的 KRR。把 KRR、VPA 建议模式和 Kubecost 给出的建议交叉对比，比单信任任何一个工具的数字更可靠。

把容量 vs 请求作为北极星指标

最能告诉你集群效率的比率是，跨 CPU 和内存的 总 pod 请求 ÷ 总节点可分配容量：你付费的容量里有多少其实被 pod 申领了。这也是 Kubecost 请求合理化所依据的指标。Kubecost 自带若干目标值，建议是相对它们计算出来的：Production 0.65、Development 0.80、High Availability 0.50(Cluster Right-Sizing API)。低于这个值，你扛着一堆没人申领的容量；高于这个值，你就把该集群类应当保留的余量花掉了。Kubecost 还会根据上下文挑选用于计算的利用率：Development 用趋势 85 分位，Production 用 98 分位，HA 用 99.9 分位，而且只在一天的窗口里如此，更长的窗口使用最大使用量。常被引用的“85 分位”其实只是 Development 在一天窗口里的默认值，并不是一个普适设置。

你要盯的是这个比率；能去动它的是自动扩缩器(Karpenter、Cluster Autoscaler)，但前提是请求是诚实的。这就是为什么 Kubecost 的请求合理化坐落在任何自动扩缩方案的上游。自动扩缩器对请求做出反应；Kubecost 告诉你那些请求是否反映了现实。

最近几天的数据按设计就是方向性的：对账需要一整天的账单数据，所以在大约 48 小时的窗口里，除非能证明某个节点不是按需付费，否则成本会维持在公开的按需价格上；Spot 只有通过单独配置的 AWS Spot 数据源(Cloud Billing Integrations)才能更早做到准确。把效率（它独立于已对账的价格）与成本分开来读。 Node Group Sizing（也就是之前的 Cluster Right-Sizing，在 v3.0 里重写了一遍）把这点变成一个可执行的动作：它在一个可配置的窗口里，把集群内的 CPU、RAM、GPU 利用率与节点容量做对比，然后按节点组建议要么改节点数，要么换实例类型。它可以从预设画像运行，也可以从自定义指标运行（usage.max/p95/p85/avg 或 request.max/avg），每种资源都有一个目标利用率阈值，且永远不会低于平均请求资源。它通过每家提供商的标准标签来识别节点组，所以在 EKS、AKS 和 GKE 上不需要额外配置就能工作(v3.x 文档)。

找出本可以不必常开的工作负载

把分摊和合理化都处理完之后，再去看那些其实没必要却一天 24 小时、天天都在跑的工作负载。在一个平台团队的复盘中，31% 的工作负载几乎全天 CPU 使用率不到 25%，但 Kubernetes 成本一年里还是涨了大约 18%。这是因为工程师花了大量时间调容量、处理告警，而每个团队都按自己的方式设置自动扩缩规则。

分类大致落在三类。真正配置过重的生产服务，放回上面的合理化回路。非生产环境（dev、integration、demo）几乎不需要在周末或夜间运行；在这一类里，定时缩到零是 ROI 最高的改动。能容忍重试的批处理和无状态工作负载是 Spot 实例的候选，代价是一两分钟的中断通知，换来大约 90% 的折扣。

Kubecost 能帮你找出被低利用的工作负载。借助 Kubecost 3.0 的 Advanced Filters，你可以直接在 UI 里用 AND/OR 条件按命名空间、标签或服务快速排序工作负载，而不必切换到其他工具中处理。

分别追踪承诺的覆盖率与利用率

预留容量和节省承诺是不必要云成本的常见来源。团队要么忽略它们，按完整的按需价付费；要么买了之后忘了检查是否在用，把折扣留在已经不再需要的资源上。有两个重要指标要看，而且很容易混在一起：

• 覆盖率指的是你常规使用中有多少被承诺保护起来了。
• 利用率指的是你买的承诺里实际用了多少。

每家云厂商的工具不同，但都可以归入三种主要类型，而且计算方式各处都一样：

一个好的做法是把承诺利用率维持在 80% 到 95% 之间，而不是非要奔着 100% 去。冲 100% 等于不给日常变动留任何余地，比如移除未使用的实例、换实例类型、应对流量下降。它在季度复盘里看起来很高效，但会给日常运营带来问题。覆盖率方面，把目标设在 60% 到 75% 是合理的：这个区间既能拿到不错的折扣，又能给每个季度的变动留出空间。这些区间来自实践经验，不是云厂商定下来的规则。

在 Kubecost 里，在真正的云账单出来之前，成本会先用云厂商的公开按需价做估算。账单一般在大约 48 小时内可用，届时 Kubecost 会用真实成本去更新估算。这次更新会包含 Reserved Instances、Savings Plans、约定使用折扣、Spot 价格，以及你可能拥有的任何特殊费率(比如 Enterprise Discount Program)。

何时该换成商业 FinOps 平台？

大多数团队应该从开源 chart 起步。等你的需求长大之后，再去考虑商业层。

如果你只是要在少数几个集群上做按命名空间分摊、基本建议和 Slack 告警，那么开源版本就够了。但如果你管理着横跨多个云的大量集群、需要自动修复、想要厂商托管的历史，或者要给财务团队提供详细且对账过的折扣数字，那么商业平台就值得投入。决策应当基于这些需求，而不仅仅是仪表盘看着好不好看。

运营的现实

• ClickHouse 加统一代理替换了老栈。 在 v3 里，2.x 时代的 DuckDB 存储被换成了 ClickHouse 数据库。这一改动让分摊和云成本 API 在规模上都更快也更可靠。它还移除了对 Prometheus 的依赖，减少了内存占用，简化了部署，同时仍然提供 OpenCost 标准的指标。

• 历史是一项主动选择，而不是默认。 不管存储后端是什么，保留窗口决定了你能做的同比/环比报告的上限。月报至少需要 30 天；同比则需要一年。如果集群内保留的成本上涨得比构建分层流水线的工程时间还快，就把冷数据分层到对象存储里去。

• 对账延迟是结构性的。 24–48 小时的账单对账延迟是云厂商账单导出的属性，而不是 Kubecost 的属性。围绕它构建你的运营模型：讨论上周的事，而不是昨天的事。

• 多集群需要明确策略。 开源 Kubecost 可以跨集群联邦，但体验比商业的多集群聚合器更糙。超过五六个集群时，要早点决定是按集群跑 Kubecost，在外部（比如自家的数据仓库）做聚合，还是付钱走商业的多集群路线。两条路都能站得住脚；但不能在两种路线之间摇摆。

• EKS 附加组件提供了一条快速上手的路径。 Kubecost v3 免费层有 30 天 10 万美元的支出上限，而 Amazon EKS 优化版 Kubecost 套件被 AWS 列为不受该上限限制。

• 运营模型才是交付物。 一个团队装上 Kubecost 却不安排定期复盘，会和没有 FinOps 工具的团队一样漂移。标准做法是组一个小的 FinOps 小组（比如一个平台工程师、一个财务分析师、一个轮值 SRE），每周碰一次，复盘容量 vs 请求比、找出过度预留最严重的工作负载、检查月度成本变化显著的命名空间。对更小的团队，每两周由平台工程师和 CTO 做一次 30 分钟的复盘也能拿到同样的效果。

一个务实的建议

如果你正在为某个 Kubernetes 平台考虑 FinOps 思路，而且没有合同义务必须选商业产品，那就从用开源 Kubecost 3.x 跑个试点开始。安装可以在一个下午之内完成。至少把一个命名空间分配给一位指定的负责人，给一个团队提供两个星期的请求 vs 使用量仪表盘，并在平台团队都能看到的频道里共享容量 vs 请求比。如果对这些指标的定期复盘成了日常，FinOps 就已经落地；如果没有，引入商业平台并不能解决底层问题。