Kubernetes 成本工具选型与迁移：用双轨证据替代功能表
团队把旧成本平台替换成新平台后，第一张日报就引发了争议：集群总额下降了 12%，平台团队认为优化见效，财务却发现云发票没有同步下降。继续追查才发现，旧平台把 Idle 分摊给业务，新平台保留 __idle__；旧平台使用摊销后净成本，新平台使用目录价；旧数据按自然日聚合，新数据按 UTC 窗口查询。迁移技术上已经“成功”，成本含义却被换掉了。
成本工具迁移不是 Dashboard 搬家。它迁移的是资源身份、时间窗口、价格语义、分摊规则、历史水位、访问权限和组织责任。只比较页面总额，可能在两边同时算错时得到漂亮的一致；只比较功能勾选，又无法知道数据能否导出、权限能否收敛、退出时能否带走证据。
先判断团队缺的是哪一种能力
选型起点不是产品名称，而是决策缺口。
OpenCost 提供厂商中立的成本规范、开源分配引擎、API 和基础 UI，适合希望自主管理 Prometheus、价格源、查询与二次集成的团队。它把 Kubernetes Allocation、Assets 与 Cloud Costs 分开，开放模型，但不会天然提供完整财务关账、企业权限、预算审批和自动治理流程。
Kubecost 使用 OpenCost 分配思想构建产品化平台。3.2.1 发行线由 FinOps Agent、Aggregator、Cloud Costs、Frontend 以及可选组件组成，不是 OpenCost 的另一个 UI，也不是“同一产品的付费版”。它增加 ETL、统一多集群、账单对账、团队权限、报告、优化动作和支持能力；Free 与 Enterprise 的边界必须按实际版本核对，不能把商业能力反推成 OpenCost 标准能力。
云厂商原生成本能力更接近账单事实和账号治理。它们通常更了解本云折扣、credit、发票实体和托管 Kubernetes 映射，但跨云模型、工作负载粒度、更新时间和可导出字段各不相同。原生能力也不是免费的数据平面：账单导出、查询引擎、对象存储和跨区网络都可能产生费用。
因此，真正的选择通常是组合：云账单负责 invoice truth，OpenCost/Kubecost 负责 workload allocation，组织数据仓库负责历史、FOCUS 规范化和财务规则。试图让一个工具独占三层事实，最终往往是在隐藏无法解释的差异。
建立不可被产品 UI 改写的成本契约
在安装候选工具前，先把组织要长期持有的数据契约写进仓库。示例只包含非敏感字段：
apiVersion: finops.example.io/v1
kind: CostEvidenceContract
metadata:
name: kubernetes-allocation
spec:
identity:
clusterKey: finops.example.io/cluster-id
ownerLabel: finops.example.io/owner
costCenterLabel: finops.example.io/cost-center
time:
timezone: UTC
closedWindow: previous-complete-day
freshnessField: max_observed_at
money:
currency: CNY
allocationRate: modeled
invoiceRate: amortized-net
buckets:
preserve: [direct, shared, idle, unallocated, overhead]
invariants:
- allocated_plus_special_buckets_equals_source_total
- no_duplicate_cluster_resource_window
- missing_owner_is_never_silently_dropped
evidence:
retainRaw: true
retainQueryParameters: true
retainRuleRevision: trueclusterKey 不能使用可变显示名；集群重建、改名和多云迁移都要保留历史映射。owner 与 cost center 标签进入指标和报表，只允许低基数、非敏感值。closedWindow 避免拿尚未完成的自然日与已关账窗口比较。allocationRate 与 invoiceRate 明确模型价和实付价是两条轨道，防止某个平台切换默认价格后被误判为节省。
五类 bucket 必须保留。Direct 是直接归属成本；Shared 是显式共享规则；Idle 是容量未被工作负载承接的差额；Unallocated 是归属维度缺失；Overhead 是集群管理或其他明确附加成本。产品允许隐藏某个 bucket，不代表组织契约允许把它从总额中删除。
用证据面选型，而不是统计功能数量
数据获取与可移植性
检查候选工具能否导出 Allocation、Assets、Cloud Cost 的原始或稳定 API，是否保留查询窗口、currency、idle/shared 参数、cluster ID、rule revision 和数据水位。API 存在不等于历史可迁移；还要验证分页、大窗口、速率限制、schema 演进和删除后能否离线复算。
OpenCost 的主入口是 /allocation、/assets 与 /cloudCost，Kubernetes Allocation 历史依赖 Prometheus 或兼容后端。Kubecost 3.x 使用新的 Agent/Aggregator 结构，产品 API 与 OpenCost 原生 API 路径不同；其 Aggregator 数据库、联邦对象存储、报告和团队权限不能原样导入 OpenCost。云原生服务则可能只提供成本导出表或受限视图，需要先确认可获得粒度和延迟。
价格与对账能力
候选工具必须能区分目录价、有效价、摊销价、credit、税费、退款与承诺折扣。能显示“节省金额”不代表能与发票核对。要求它同时展示模型成本和账单成本，或者允许把两者作为不同数据集关联。
身份和权限
把权限拆成四层：Kubernetes 只读采集、云价格读取、云账单读取、治理动作写入。只需要观测时，不应授予修改 Deployment、ResourceQuota 或 Namespace 的权限。Kubecost Network Costs 需要更高的宿主访问，Actions/Cluster Controller 会增加写权限；OpenCost Cloud Costs 需要云账单身份；云原生服务还可能跨账号读取账单。每一层都要能独立关闭和审计。
规模与运行成本
Prometheus series、查询窗口、标签基数、Aggregator 磁盘 IOPS、对象存储、账单查询费和 API payload 都是成本平台自身的容量输入。单集群 UI 流畅不能证明多集群日批能完成。用最大集群、最长保留窗口和高基数反例压测，记录 ingestion lag、查询 p95、失败率、磁盘增长和月度平台成本。
退出与支持
确认 license、Free/Enterprise 边界、升级支持线、数据导出、凭证撤销和残留资源。OpenCost 是 Apache-2.0 的开源项目；Kubecost 使用 OpenCost 引擎并提供额外产品能力，两者不能按“免费版/付费版”归类。商业支持、SSO、统一多集群和 Actions 边界会随版本变化，采购承诺写进合同和架构记录，不写成永久产品事实。
先搭建隔离双轨，不要原地覆盖
双轨环境必须拥有不同 namespace、release name、Service、Ingress 和数据存储。读取同一集群可以共享只读 Kubernetes 事实，但不能让两个工具同时执行 rightsizing、ResourceQuota 或工作负载变更。云账单身份也应分别可审计，避免一套静态 key 在两边复制。
以 OpenCost 为候选时，固定 1.120.4 和 Chart 2.5.26，记录 Prometheus endpoint 与 cluster ID；以 Kubecost 为候选时，固定 Chart 3.2.1，设置全局唯一 global.clusterId，并让 3.x Chart 管理它兼容的 FinOps Agent 版本。不要把 Kubecost 2.x cost-analyzer values 直接套到 3.x，也不要把 OpenCost /allocation 与 Kubecost /model/allocation 当成同一 API。
先保存两边配置与身份：
kubectl get ns opencost kubecost-next
helm list -A | grep -E 'opencost|kubecost'
kubectl auth can-i --as=system:serviceaccount:opencost:opencost get pods -A
kubectl get clusterrole,clusterrolebinding | grep -E 'opencost|kubecost'
kubectl get networkpolicy,ingress -A | grep -E 'opencost|kubecost'再为两个 API 建立仅本地可达的端口转发，保存原始响应：
kubectl -n opencost port-forward deployment/opencost 9003:9003
kubectl -n kubecost-next get service
kubectl -n kubecost-next port-forward service/<kubecost-api-service> 9091:<api-port>
mkdir -p migration-evidence/raw
curl -fsS 'http://127.0.0.1:9003/allocation?window=24h&aggregate=namespace' \
> migration-evidence/raw/opencost-allocation.json
# Kubecost 的 API 地址、认证方式与端口以目标 3.x 安装生成的 Service 和 API 目录为准。
curl -fsS -H "X-API-KEY: ${KUBECOST_API_KEY:?}" \
"${KUBECOST_API_URL:?}/model/allocation?window=24h&aggregate=namespace" \
> migration-evidence/raw/kubecost-allocation.json
sha256sum migration-evidence/raw/*.json > migration-evidence/raw/SHA256SUMSAPI key 只从密钥系统注入，不能进入命令历史、CI 日志或证据包。若使用 Free 安装且没有该认证能力，就保持 API 在 ClusterIP/port-forward 边界内，不应为了脚本方便直接公网暴露。
把两个产品适配成同一份规范化明细
不要直接比较两份嵌套 JSON。分别为每个产品维护小型 adapter，把数据转换为组织持有的规范化 CSV：
window_start,window_end,cluster_id,namespace,owner,currency,
direct_cost,shared_cost,idle_cost,unallocated_cost,overhead_cost,
source_tool,source_revision,rule_revision,max_observed_atadapter 负责字段映射，不负责“修正”差异。缺失 owner 必须输出空值或 __unallocated__；没有某类成本必须标记 unsupported/missing，不能填零；金额使用 decimal，币种转换单独记录汇率来源和生效窗口。每次转换保存原始文件 hash、adapter revision 和 schema version。
下面的检查器可以直接验证两份规范化 CSV。它不要求金额完全一致，而是先检查各自守恒，再输出同一 namespace 的相对差异：
#!/usr/bin/env python3
import csv
import decimal
import sys
from collections import defaultdict
D = decimal.Decimal
PARTS = ("direct_cost", "shared_cost", "idle_cost", "unallocated_cost", "overhead_cost")
def load(path):
rows = []
with open(path, newline="", encoding="utf-8") as f:
for row in csv.DictReader(f):
row["total"] = sum(D(row[x]) for x in PARTS)
if not row["cluster_id"] or not row["window_start"] or not row["window_end"]:
raise SystemExit(f"missing identity in {path}: {row}")
rows.append(row)
return rows
def aggregate(rows):
out = defaultdict(D)
for row in rows:
out[(row["cluster_id"], row["namespace"], row["currency"])] += row["total"]
return out
left, right = map(load, sys.argv[1:3])
a, b = aggregate(left), aggregate(right)
for key in sorted(set(a) | set(b)):
x, y = a[key], b[key]
base = max(abs(x), abs(y), D("0.01"))
print(*key, f"old={x}", f"new={y}", f"relative_delta={(y-x)/base:.4f}")python compare_cost_exports.py old-normalized.csv new-normalized.csv \
| tee migration-evidence/comparison.txt脚本中的阈值不能脱离业务基线硬编码。团队应先定义总额、namespace、owner、资产类型、特殊 bucket 和 Top N 工作负载的允许偏差，再要求所有超阈值行都有分类原因。总额接近而关键 namespace 偏差很大，仍然是迁移失败。
正向实验：证明相同窗口下的差异可解释
选择一个已关闭的完整 UTC 窗口，冻结两边价格配置和共享规则，选取三种代表性对象：带 owner 的普通 Deployment、没有 owner 的 Pod、带 PVC 的 StatefulSet。保存 Kubernetes UID、Node provider ID、PVC/PV、Service 和对应账单资源 ID。
依次验证：
两边都能发现三个对象，缺标签对象都进入未分配维度，而不是消失。每边内部满足 direct、shared、idle、unallocated、overhead 加总等于其源总额。CPU/RAM 差异能由 request/usage、采样分辨率或价格源解释。
PV、LB、network 的非零或缺失状态能由指标与 provider 映射解释。模型成本与云账单成本保留为不同列，不为追求一致强行覆盖。
预期产物不是“差异为零”，而是一份差异分类表。常见类别包括价格源差异、窗口边界、采样缺口、标签映射、idle 规则、shared 规则、资产映射、账单迟到和产品不支持。每一类都有 owner、证据链接和处理结论。连续多个关闭窗口中，未解释差额不再增长，才说明双轨进入稳定状态。
反向实验：故意制造一个看似合理的假一致
复制一份规范化数据，把旧平台的 idle_cost 全部加到 direct_cost，再从新平台删除 __unallocated__ 行。两个报表都可能展示“业务成本占比更高”，甚至总额相近，但分类语义已被破坏。
#!/usr/bin/env python3
import csv
with open("new-normalized.csv", newline="", encoding="utf-8") as src, \
open("bad-normalized.csv", "w", newline="", encoding="utf-8") as dst:
reader = csv.DictReader(src)
writer = csv.DictWriter(dst, fieldnames=reader.fieldnames)
writer.writeheader()
for row in reader:
if row["namespace"] == "__unallocated__":
continue
row["direct_cost"] = str(float(row["direct_cost"]) + float(row["idle_cost"]))
row["idle_cost"] = "0"
writer.writerow(row)运行比较器后，总额偏差可能不大，但 bucket 覆盖率检查应立即失败：Idle 被清零，Unallocated 行消失，直接成本异常上升。这个反例证明只设“总额差异小于某百分比”无法保护迁移。至少还要监控特殊 bucket 占比、owner coverage、资产覆盖率、freshness 和局部差异。
修复不是调低阈值，而是恢复原始 bucket，统一规则或明确接受差异。任何重分类都写成版本化规则，保存重算前后金额与审批记录。
历史数据通常不能直接搬，要设计连续性
OpenCost 的 Kubernetes 历史主要在 Prometheus；Kubecost 3.x 的 Agent、Aggregator、本地数据库和可选联邦存储有自己的生命周期；云原生成本数据位于账单导出表。迁移时常见三种策略：
原地导入：只有新工具明确支持旧 schema、版本和校验时采用。未经支持的数据库复制会把“能启动”误当“数据兼容”。历史归档加新基线：旧系统只读保留或导出到数据仓库，新系统从切换点开始写。查询层用 source revision 区分，不伪造连续曲线。双轨重算：两边都能从同一原始指标或账单重算时，在可承受窗口内回放。必须核对价格版本、schema、retention 与算力成本。
集群 ID、资源 UID 和组织标签是连接历史的关键。集群重建后 provider ID 改变时，不能仅凭同名 namespace 合并；owner 或 cost center 重组时，保留有效时间映射，避免用当前组织覆盖历史责任。
切换要有进入条件、停止条件和回滚窗口
进入切换前，至少满足：
多个关闭窗口的采集 freshness 和对象 coverage 达到基线；所有超阈值差异已分类，关键 namespace 无未解释偏差；API consumer、报表、预算和告警都完成新旧对照；
新平台 RBAC、云 IAM、NetworkPolicy、SSO/API key 已审计；所有写动作保持关闭，或已完成单独审批与回滚实验；旧平台仍可只读查询，原始数据和配置可恢复。
切换顺序是先 API consumer，再报表和通知，最后才是治理动作。DNS/Ingress 切换只改变入口，不迁移历史与权限。若出现数据水位倒退、关键维度消失、查询容量超标、未解释差额增长或写动作重复执行，立即停止并恢复旧入口。
回滚不是重新显示旧 Dashboard。还要恢复旧 API consumer、规则 revision、告警路由和身份，并关闭新平台的写权限。双轨期间同一业务动作只能有一个 controller owner，成本建议可以并行，资源修改不能并行。
权限、凭证与敏感成本数据
成本数据会暴露账号、资源 ID、命名空间、客户或租户映射、合同折扣、采购策略与业务规模。平台迁移时最容易因为“只是报表”而放宽访问。
运行身份按功能拆分：Kubernetes 采集器只读；云价格身份只读价格；账单身份只读指定导出；数据仓库 writer 只能写目标前缀；API consumer 按组织维度授权；Actions 身份独立审批。Network Costs 需要宿主网络或 /proc 时，单独评审特权和数据面影响。
Secret 迁移采用“新身份建立、双轨审计、调用方切换、旧身份撤销”的顺序。只从 Secret 删除 key 而不在云端撤销，旧凭证仍然有效；只撤销身份而不删除对象存储策略、Ingress 和 API key，也没有完成退出。
日志和差异报告只保留必要身份，资源 ARN、账号和折扣字段按敏感级别脱敏。诊断包、UI 截图和原始 JSON 都进入受控存储，设置保留期与删除证明。
升级与产品迁移要分开
产品内升级和跨产品迁移是两个风险不同的变更。OpenCost 升级要比较 Chart、镜像、RBAC、Prometheus 查询和 API schema；Kubecost 从 2.x 到 3.x 涉及 Agent、Aggregator、仓库与 values 结构变化，官方建议平行安装并验证后切流。不要把版本升级与产品迁移塞进同一窗口，否则出现偏差时无法区分代码、配置还是模型变化。
每次升级保存 helm get values --all、manifest、镜像 digest、API 样本、数据水位、规则 revision 和容量指标。新版本先在双轨环境重放代表性查询，确认历史、特殊 bucket、资产和账单没有静默丢失，再进入生产。
退出时核销控制面、数据面和费用
卸载前登记并导出：原始 Allocation/Assets/Cloud Cost、规范化表、标签映射、共享规则、价格配置、报表、预算、告警、API consumer、SSO/RBAC、对象存储、PVC 和云 IAM。商业产品还要确认合同数据导出、支持工单和许可终止责任。
按依赖逆序停止：
冻结 Actions 与自动治理，撤销工作负载写权限。切走 API consumer、Dashboard、通知和定时导出。导出并校验历史，记录保留 owner 与删除期限。
关闭 Ingress、Service、MCP/插件等访问入口。撤销 API key、云身份、对象存储和账单读取权限。卸载 Helm release，检查带 resource-policy: keep 的 PVC。
核销负载均衡器、磁盘、对象存储、查询任务、DNS 和日志费用。
最终证据应能回答：旧入口不可调用、旧凭证不可使用、旧 controller 不再写资源、保留数据仍可按契约读取、应删除资产不再计费。完成这些检查，才算迁移结束。
架构师的选择结论
选择 OpenCost，意味着团队愿意持有 Prometheus、价格、API 集成、历史和治理流程；选择 Kubecost，意味着用产品化能力换取新的 Aggregator、权限、存储、版本和商业依赖；选择云原生能力，意味着接受云内语义和跨云可移植性的边界。三者也可以分层组合，但必须明确哪一层是模型、哪一层是账单、哪一层执行治理。
最可靠的选型结论不是“某产品功能最多”，而是目标工具在代表性窗口中证明：数据可取得、差异可解释、权限可收敛、容量可承受、历史可连接、失败可回滚、退出能核销。这样形成的工具链才不会在下一次迁移时再次把成本含义交给某个界面默认值。