2. 云原生成本模型：从计费到分摊的完整链路
成本优化不能仅凭经验或事后账单。要真正实现 FinOps 协同，团队必须建立统一的成本模型，理解公有云计费逻辑、Kubernetes 资源语义以及成本分摊的映射关系。本章将拆解这三层模型，为后续的资源画像与优化动作奠定数据基础。
2.1 公有云计费模型：计算 / 存储 / 网络
公有云厂商（AWS、Azure、GCP、阿里云等）的计费项虽然名称各异，但底层逻辑高度一致。核心计费维度可归纳为三类：计算、存储、网络。
| 计费维度 | 典型计费方式 | 关键参数 | 成本波动因素 |
|---|---|---|---|
| 计算 | 按实例规格 / vCPU-小时 / 预留实例 / Spot | vCPU 核数、内存大小、实例族、操作系统 | 规格选择、购买模式（按需 vs 预留）、Spot 中断率 |
| 存储 | 按容量 / IOPS / 吞吐量 / 请求次数 | 存储类型（SSD/HDD/对象存储）、冗余策略、访问频次 | 数据生命周期、快照频率、跨区域复制 |
| 网络 | 按出站流量 / 跨 AZ 流量 / NAT 网关 / LB | 流量方向、区域、带宽峰值、负载均衡器数量 | 服务间调用拓扑、Ingress 策略、数据本地化程度 |
FinOps 实践提示： 在公有云账单中，计算通常占总成本的 50%-70%，是优化的首要目标。但 网络 成本往往被忽视，尤其是在跨可用区（AZ）或跨 Region 的微服务调用中，流量费用可能超过计算本身。
2.2 Kubernetes 资源模型：Request / Limit / Overhead
Kubernetes 通过 Request 和 Limit 两个参数定义容器的资源边界，而 Overhead 则反映了运行时基础设施的额外消耗。理解这三者的关系，是准确计算 Pod 真实成本的前提。
- Request：容器保证能获得的资源量，也是调度器进行节点资源分配的依据。集群中所有 Pod 的 Request 总和不能超过节点容量。
- Limit：容器可使用的资源上限。当节点资源充足时，容器可以突发使用到 Limit；当节点资源紧张时，容器会被限制在 Request 附近。
- Overhead：容器运行时基础设施（如 Sidecar、DaemonSet、kubelet 自身）消耗的资源。这部分成本通常被忽略，但在大规模集群中占比可观。
成本计算核心公式：
Pod 有效成本 = (Request + Overhead) × 单价 × 运行时长节点利用率 = 所有 Pod Request 总和 / 节点总容量
下图展示了从容器 Request/Limit 到节点资源分配，再到公有云计费实例的完整映射关系：
2.3 成本分摊逻辑：从集群账单到业务单元
成本分摊是 FinOps 落地的关键环节。没有准确的分摊，优化动作就缺乏数据支撑。分摊逻辑需要解决两个核心问题：分摊粒度和分摊方法。
2.3.1 分摊粒度选择
| 分摊粒度 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| Namespace | 多团队共享集群，按项目隔离 | 实现简单，K8s 原生支持 | 无法区分同一 Namespace 内的不同应用 |
| Deployment / StatefulSet | 微服务架构，按服务维度核算 | 粒度适中，与 CI/CD 对齐 | 需要额外标签管理 |
| Pod | 精细化成本分析，定位异常 Pod | 最细粒度，可追溯 | 数据量大，需要聚合查询 |
| Label / Annotation | 自定义维度（环境、部门、成本中心） | 灵活，可组合 | 依赖团队标签规范 |
2.3.2 分摊方法：按 Request vs 按实际使用
分摊方法的选择直接影响成本数据的公平性和优化导向：
- 按 Request 分摊：以 Pod 声明的 Request 为权重，将节点总成本分摊到各 Pod。这种方法鼓励团队合理设置 Request，避免过度申请。
- 按实际使用分摊：以 Prometheus 等监控系统采集的实际资源使用量为权重。这种方法更公平，但需要额外的监控基础设施，且可能掩盖资源浪费。
常见误区： 很多团队直接使用公有云账单除以 Pod 数量进行平均分摊。这种做法会严重扭曲成本数据——一个 0.5 core 的 Sidecar 和一个 8 core 的业务 Pod 被分摊相同成本，导致优化决策失准。
下图展示了从公有云账单到业务单元的分摊流程：
2.4 成本模型协同：FinOps 的三阶段循环
将公有云计费模型、Kubernetes 资源模型和成本分摊逻辑串联起来，就构成了 FinOps 的三阶段循环：
- 可见（Inform）：通过成本分摊逻辑，将公有云账单映射到 Namespace、Deployment、Pod 和 Label，生成业务视角的成本报表。
- 优化（Optimize）：基于资源画像数据，调整 Request/Limit、选择合适实例规格、利用预留实例和 Spot 实例，降低单位业务成本。
- 运营（Operate）：建立成本预算和告警机制，持续监控成本效率指标，推动团队形成成本意识。
关键结论： 成本模型不是静态的。随着业务规模增长和云厂商定价策略变化，分摊逻辑和优化策略需要定期校准。建议每季度进行一次成本模型审计，确保分摊公平性和优化方向正确。