跳至主要內容

Kubernetes 成本工具：从资源使用到可对账分摊

高谷深陵大约 11 分钟约 3262 字

共享集群的账单会上经常出现这样的僵局：业务 A 展示 CPU 使用率，证明自己只用了节点的一小部分；平台团队拿出 Pod requests，认为预留容量也应计费；财务看到的却只有云厂商按节点、磁盘和网络结算的总额。三方数字都是真的，却没有一条记录能够说明同一笔费用从哪个云资产出发，经过什么价格和分摊规则，最后落到哪个团队。

Kubernetes 成本工具真正解决的不是“给每个 namespace 显示一个金额”，而是把资源身份、请求与使用、资产价格、时间窗口、共享规则和账单修订连接成证据链。只有这条链可追溯、可复算、金额守恒，showback 才能解释，chargeback 才有资格进入财务流程，rightsizing 建议也才不会为了降低报表数字而破坏容量安全。

Kubernetes OpenCost Kubecost 资源使用资产账单成本分摊守恒对账权限与退出知识海报
Kubernetes 成本证据剖面从集群对象、资源遥测和云资产进入 Allocation、Assets、Cloud Cost 三个事实面，再以守恒、覆盖率和水位完成对账。高清原图

先解释一张无法对齐的账单

节点费用不等于 Pod 使用量之和。调度器按 request 预留容量，云厂商按实例、磁盘、负载均衡器和网络结算，成本工具再用价格模型和分摊政策把资产费用映射到工作负载。由此至少产生四类金额：

direct：能够直接归属给工作负载的 CPU、内存、GPU、PV 或网络成本；shared：控制面、平台 namespace、网关等按明确政策再次分摊的成本；idle：资产成本减去已承接分配后的剩余容量成本；

unallocated：成本存在，但 cluster、owner、namespace 或其他归属键缺失。

这四类不能靠隐藏来改善指标。对同一资产集合、币种和关闭窗口，应始终满足：

source_asset_cost
  = direct + shared + idle + unallocated + explicit_adjustment

explicit_adjustment 只能承载有来源的 credit、退款、税费或账单修正，不能成为吸收未知差额的万能列。若右侧小于左侧，通常有资产漏采、时间窗口错位或特殊 bucket 被过滤；若右侧大于左侧，通常是重复导入、共享成本重复分摊或一项资产被多个集群认领。

三个事实面不能互相冒充

OpenCost 与 Kubecost 都会接触 Kubernetes 成本，但同一个产品内部也存在不同事实面。

Allocation 以 cluster、namespace、controller、pod、container、label 或 annotation 聚合工作负载成本。它消费 requests、usage、持续时间和价格模型，适合回答“谁承接了多少成本”。

Assets 观察 Node、PV、负载均衡器等基础设施对象，适合回答“钱花在了哪些承载资源上”。节点能被采集并不代表其费用已经完整分配给 Pod；被删除的 PV、闲置 LB 和 NAT 流量也不会自动出现在 CPU/内存分摊里。

Cloud Cost 来自云账单导出，带有账号、服务、折扣、credit 和发票修订语义，适合回答“供应商最终记录了哪些费用”。它通常比 Allocation 晚，也未必携带足够细的 workload 身份。

因此，合理架构不是选择一个“最准确的数字”，而是保留三个事实面，并保存它们之间的映射。分钟级 Allocation 用于发现异常，日级或账期级 Cloud Cost 用于复核结算，Assets 负责解释二者之间的承载关系。

建立不会随产品更换而消失的证据契约

先把稳定键和质量规则放进版本库。产品字段可以由适配器转换，组织证据契约不能藏在某个 Dashboard 的筛选器里：

apiVersion: finops.example.io/v1
kind: KubernetesCostContract
metadata:
  name: workload-allocation
spec:
  identity:
    clusterId: finops.example.io/cluster-id
    resourceKey: provider-id-or-resource-uid
    ownerLabel: finops.example.io/owner
  window:
    timezone: UTC
    closePolicy: previous-complete-window
    watermarkField: observed_at
  money:
    currency: CNY
    modeledRate: on-demand-or-price-book
    invoiceRate: amortized-net
  preserveBuckets: [direct, shared, idle, unallocated]
  evidence:
    retainRaw: true
    retainQuery: true
    retainRuleRevision: true
  invariants:
    - allocation_plus_special_buckets_equals_source
    - resource_window_is_unique
    - missing_owner_is_visible

clusterId 必须稳定，不能直接使用可变显示名。resourceKey 优先保留云 provider ID 或 Kubernetes UID 与云资产 ID 的映射。owner 标签进入指标系统时要控制基数，且不得写入客户名、邮箱、订单号等敏感值。

模型价与发票价要分列。模型价支持及时反馈，发票价包含合同折扣和迟到修正；把后者覆盖前者，会让历史报表随账单刷新而无声变化。查询参数、规则 revision 和数据水位同样属于成本结果的一部分，没有它们就无法复算。

从只读入口跑通最小链路

已有 OpenCost 时，可以先用端口转发检查三个事实面，不必开放公网 Service：

kubectl -n opencost get deploy,pod,svc
kubectl -n opencost port-forward deployment/opencost 9003:9003

curl -fsS 'http://127.0.0.1:9003/allocation?window=60m&aggregate=namespace' > allocation.json
curl -fsS 'http://127.0.0.1:9003/assets?window=60m' > assets.json
curl -fsS 'http://127.0.0.1:9003/cloudCost?window=7d' > cloud-cost.json

三个请求都返回 JSON 只说明入口可达。继续记录响应窗口、cluster ID、聚合参数、价格类型和最大 observed_at，再检查非零记录、特殊 bucket 与金额单位。Cloud Cost 没有配置云账单时可能为空，这不是把 Allocation 当发票的理由。

没有集群也能先验证分摊守恒。创建 verify-k8s-cost.mjs：

const source = [
  { asset: "node-a", currency: "CNY", cost: 100 },
  { asset: "pv-a", currency: "CNY", cost: 20 },
];

const allocations = [
  { asset: "node-a", bucket: "direct", owner: "team-a", cost: 55 },
  { asset: "node-a", bucket: "shared", owner: "platform", cost: 15 },
  { asset: "node-a", bucket: "idle", owner: "__idle__", cost: 25 },
  { asset: "node-a", bucket: "unallocated", owner: "__unallocated__", cost: 5 },
  { asset: "pv-a", bucket: "direct", owner: "team-a", cost: 20 },
];

const sum = (rows) => rows.reduce((n, row) => n + row.cost, 0);
const sourceTotal = sum(source);
const allocatedTotal = sum(allocations);
const ownersMissing = allocations.filter((row) => !row.owner);
const duplicateKeys = allocations
  .map((row) => `${row.asset}|${row.bucket}|${row.owner}`)
  .filter((key, index, all) => all.indexOf(key) !== index);

console.log({ sourceTotal, allocatedTotal, delta: sourceTotal - allocatedTotal });
console.log({ ownersMissing: ownersMissing.length, duplicateKeys });

if (sourceTotal !== allocatedTotal || ownersMissing.length || duplicateKeys.length) {
  process.exitCode = 1;
}

执行：

node verify-k8s-cost.mjs

预期输出中的 sourceTotal 与 allocatedTotal 都是 120，delta 为 0，owner 缺失数和重复键都为空。这个实验没有模拟 OpenCost 的完整算法，它验证的是任何产品都必须接受的组织不变量。

反向实验：总额相等也可能分错团队

把 pv-a 的 owner 从 team-a 改成 team-b 后再次执行，脚本仍然通过，因为总额守恒没有被破坏。这正是成本对账最容易漏掉的错误：金额正确，身份错误。

增加预期归属检查：

const expectedOwner = new Map([
  ["node-a", "team-a"],
  ["pv-a", "team-a"],
]);

const identityErrors = allocations.filter((row) =>
  row.bucket === "direct" && expectedOwner.get(row.asset) !== row.owner
);

console.log({ identityErrors });
if (identityErrors.length) process.exitCode = 1;

现在反例应以退出码 1 结束，并打印 pv-a 的错误归属。生产质量门禁也要同时覆盖金额守恒、身份覆盖、数据新鲜度、重复率和异常修订，不能只看一个总额差值。

OpenCost、Kubecost 与云原生能力怎样组合

OpenCost 适合需要开放规范、API 和自主管理数据面的团队。它依赖 Prometheus-compatible 历史与价格配置，工程责任会落在采集覆盖、查询容量、数据保留和二次集成上。部署与 API 证据链见 OpenCost 成本分摊与 API。

Kubecost 在成本 ETL、多集群、报告、云集成和治理动作上提供更产品化的链路。只读观测与具有写权限的 Actions/Cluster Controller 必须拆开审批，网络成本组件还可能需要宿主机和特权访问。组件边界与升级方式见 Kubecost 成本监控与治理。

云厂商原生能力更接近折扣、credit 和发票实体，但 Kubernetes 粒度、延迟和导出字段各不相同。它适合作为账单事实，不应被假设成跨云统一工作负载模型。

成熟方案往往是组合而不是替代：OpenCost/Kubecost 形成 workload allocation，云账单形成 invoice truth，组织数仓保存版本化规则与长期证据。产品选择应根据数据可取得性、可复算性、权限、容量、出口和团队 owner 判断，而不是比较 Dashboard 数量。双轨切换方法见 Kubernetes 成本工具选型与迁移。

Ready 但没有可信成本时怎样排查

先按数据链分层，不要从 UI 刷新开始猜：

对象层：检查 Pod、Node、PV/PVC、Service 与 controller 是否可被运行身份读取，provider ID 和 cluster ID 是否稳定。指标层：检查 requests、usage、kube-state-metrics 和容器持续时间是否覆盖目标窗口；短任务是否在采集间隔内消失。价格层：检查节点规格、区域、币种、GPU、磁盘和自定义 price book 是否匹配；未知实例不能静默按零计价。

分摊层：记录 aggregate、idle、share、filter 与规则 revision；同一查询必须可以重放。账单层：检查导出水位、账号 scope、折扣、credit、税费和迟到修正；未关闭窗口不进入 chargeback。身份层：检查 cluster、namespace、workload、owner 与 cost center 的覆盖率，缺失值进入 unallocated，不能被过滤。

常见现象也能帮助定位：Allocation 为空而 Assets 非空，多半是 Prometheus 查询或工作负载指标链故障；Allocation 有值而 Cloud Cost 为空，多半是云账单集成或延迟；成本突然减半但资源未变，先检查价格类型、idle 规则和窗口；总额接近但团队差异剧烈，优先检查资源身份和共享规则。

权限和数据边界决定平台能否长期运行

权限至少拆成 Kubernetes 只读采集、指标查询、云价格读取、云账单读取和治理动作写入五层。日常查询身份不应拥有修改 Deployment、ResourceQuota 或 NodePool 的能力；需要执行优化动作时使用独立 ServiceAccount、独立审批和完整审计。

云账单会暴露账号结构、资源 ID、标签、合同折扣、业务规模与租户关系。原始导出进入独立数据域，按付款账号和用途授权；面向研发的视图只提供其负责范围，并对合同字段做列级隔离。Prometheus 标签同样不能承载客户标识或 Secret，因为高基数和敏感数据会同时扩大容量、泄露与删除成本。

平台自身也有成本。Prometheus series、历史保留、查询 resolution、标签基数、多集群 fan-out、云账单扫描量和对象存储都会增长。容量验收应记录采集延迟、查询 p95、失败率、存储增长、每日处理窗口和平台月成本，并用最大集群与最长窗口测试，而不是只观察一个小集群页面。

把节省结论放回系统风险中

看到低 usage 时，不能直接把 request 改成推荐值。先确认 SLO、峰值窗口、启动抖动、故障转移容量和调度碎片，再由家族 48 的伸缩与调度工具实施变更。成本平台负责提出候选、保留基线并验证 realized savings，不应越权成为自动伸缩器。

有效节省至少需要四段证据：变更前同口径基线、候选规则与审批、发布后的性能和可靠性结果、关闭账单窗口中的实际费用变化。任何一段缺失，都只能称为建议或估算，不能称为已实现节省。

升级、迁移和退出要先保住证据

升级成本平台时先冻结 schema、API、价格类型和规则 revision，平行运行新旧链路，在相同关闭窗口比较金额、身份、特殊 bucket、新鲜度和查询容量。差异不必为零，但必须能被价格、窗口、规则或源数据变化解释。新链路稳定前保持旧链路只读，禁止两个平台同时执行治理动作。

退出顺序从导出开始：保存原始响应、历史窗口、规则、查询参数、数据字典和审计记录；撤销云账单与 Kubernetes 身份；停止写动作；确认 Prometheus、对象存储和报表没有遗留消费者；再删除 Deployment、Service、PVC 与保留数据。最后核销负载均衡器、磁盘、对象存储、查询服务和商业授权费用。

当团队能够从一笔 workload 成本回到资源、窗口、价格、规则和云账单源行，也能在产品不可用时用导出数据复算，Kubernetes 成本工具才从“报表插件”变成了可治理的工程系统。

跳到正文