在多云与混合云架构成为常态的今天，Kubernetes 集群的成本治理面临一个核心痛点：内部估算模型与云厂商实际账单之间存在结构性鸿沟。团队使用 Kubecost、OpenCost 等工具基于 CPU / 内存请求量推算成本，而财务部门收到的 AWS 发票却基于 EC2 实例小时、EBS 存储、数据传输等维度计费。两套数据格式不兼容、粒度不对齐，导致月末对账时差异难以解释，成本分摊争议频发。
FOCUS（FinOps Open Cost and Usage Specification）规范的出现，为这一困境提供了标准化的解决路径。作为由 FinOps Foundation 主导的开源项目，FOCUS 定义了一套统一的云成本与使用数据 schema，目标是消除跨云、跨服务的数据格式碎片化。AWS 于 2024 年 6 月推出 FOCUS 1.0 Data Exports（Preview），允许用户将成本与使用数据以 FOCUS 标准格式导出至 S3，为 Kubernetes 成本对账流水线的构建奠定了基础。
FOCUS 规范的核心价值
FOCUS 1.0 的核心贡献在于标准化了三个关键维度。首先是成本列的统一：规范明确定义了 ListCost（目录价）、BilledCost（实际计费价）、EffectiveCost（有效成本，含折扣分摊）三类成本指标，使折扣验证可通过单一计算（EffectiveCost/ListCost）完成，无需再处理各云厂商迥异的折扣表达逻辑。其次是 schema 的一致性：所有账单数据类型在跨源场景下保持相同的列定义，AWS 在标准 43 列之外额外提供 5 个带 "x_" 前缀的专属列（如 x_UsageType、x_CostCategories），既保证互操作性又保留平台特性。最后是通用值集：FOCUS 强制统一计量单位表达，例如时间单位统一使用 "Hours"，杜绝 "hr"/"hrs"/"hour" 等变体导致的聚合错误。
FOCUS 1.2（2025 年 5 月发布）进一步扩展了适用范围，新增 SaaS 与 PaaS 数据源支持，引入 InvoiceId 字段实现发票级对账，并支持多币种标准化。这意味着 Kubernetes 集群中引用的第三方可观测性服务、托管数据库等 SaaS 成本，可与基础设施成本纳入同一分析框架。
AWS FOCUS 导出与 Kubernetes 成本映射
在 AWS 控制台中启用 FOCUS 1.0 Data Exports 后，数据将以小时粒度、资源级粒度投递至指定 S3 存储桶。导出表包含 48 列数据，其中 43 列遵循 FOCUS 1.0 规范，5 列为 AWS 专属扩展。这一数据结构可直接对接 Kubernetes 成本对账需求：通过 ResourceId、x_ResourceTags 等字段，可将 EC2 实例、EBS 卷、EKS 控制平面费用与集群内的命名空间、工作负载进行关联。
构建对账流水线的关键在于标签策略的规范化。建议在 EKS 集群层面实施强制标签注入：通过 AWS Load Balancer Controller、EBS CSI Driver 等组件的自定义标签配置，确保所有云资源自动继承集群标识（如 eks-cluster-name）、命名空间（k8s-namespace）、应用名称（app-name）等维度。这些标签将随 CUR/FOCUS 数据导出，成为成本分摊与对账的关联键。
对账逻辑的核心是比较两个数值：一是基于 Kubernetes 资源请求量（request）与云厂商定价 API 计算出的预估成本，二是 FOCUS 导出中的 BilledCost 实际值。理想状态下，两者差异应控制在 5% 以内，偏差主要来源于 Spot 实例中断、预留实例折扣分摊、数据传输费用等预估模型难以精确捕捉的变量。
可落地的对账流水线架构
一个可审计的 Kubernetes 成本对账流水线应包含以下组件：
数据摄取层：配置 FOCUS 1.0 Data Exports 自动投递至 S3，同时通过 Kubecost/OpenCost 的 API 或导出功能获取集群内部成本估算数据。建议设置每日增量同步，避免月末集中处理带来的计算压力。
转换与对齐层：使用 Apache Spark、dbt 或自定义 ETL 脚本，将 FOCUS 数据与 Kubernetes 估算数据转换为统一维度。关键映射包括：将 FOCUS 的 ResourceId 与 Kubernetes 的 node-name 关联，通过 x_ResourceTags 提取命名空间与应用归属，将 ListCost 与内部预估的目录价进行对比。
差异分析层：建立三层监控阈值：差异率 <5% 视为正常波动；5%-15% 触发告警，需排查标签缺失或资源泄漏；> 15% 启动人工审计，检查账单异常或模型缺陷。差异归因应区分系统性偏差（如预估模型未覆盖的数据传输费用）与偶发性偏差（如 Spot 实例大规模中断）。
报告与审计层：通过 QuickSight、Grafana 或自定义 Dashboard 展示对账结果，关键指标包括：集群级成本差异率、命名空间成本分摊准确度、发票级对账状态（利用 FOCUS 1.2 的 InvoiceId）。审计日志应保留原始 FOCUS 数据与 Kubernetes 估算数据的快照，支持历史回溯。
实施检查清单与限制
在落地 FOCUS 对账流水线前，需确认以下前提条件：
- 账户已启用折扣自动化（Discount Automation），否则无法生成正确的 BilledCost 与 EffectiveCost 列
- 每个 AWS 账户最多创建 2 个免费 FOCUS 导出，需合理规划导出频率与保留周期
- 标签策略需在集群与云资源层面保持一致，建议使用 AWS Tag Policies 实施强制合规
- 预估成本模型需定期校准，至少每季度根据实际账单调整 CPU / 内存的单价系数
需要留意的是，FOCUS 1.0 目前仍处于 Preview 状态，AWS 正在持续迭代。生产环境建议保留 CUR 作为备份数据源，并关注 FOCUS 1.2 的 GA 进展，以便及时迁移至更完善的发票级对账能力。
通过 CUR/FOCUS 统一账单格式，Kubernetes 成本治理从 "估算黑盒" 走向 "可审计对账"，为 FinOps 团队提供了跨云、跨服务的成本透明度基础。
参考来源
- AWS Cloud Financial Management Blog: "Announcing Data Exports for FOCUS 1.0 (Preview) in AWS Billing and Cost Management", 2024-06-21
- FOCUS Specification: FinOps Open Cost and Usage Specification v1.1/v1.2, FinOps Foundation
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。