3. 成本分摊核心指标：CPU、内存、存储、网络流量的计量与计价模型

在云原生架构中，成本分摊的准确性直接取决于对底层资源消耗的计量粒度与计价模型。本章将深入剖析 CPU、内存、存储、网络流量四大核心指标的计量单位、采集方式以及多租户场景下的计价分摊策略，为后续项目部署中的成本归属提供数学基础。

3.1 核心指标计量维度总览

下表对比了四大资源在 Kubernetes 环境下的计量单位、采集源与分摊粒度，是构建成本模型的起点。

3.2 CPU 计量与计价模型

3.2.1 计量原理

CPU 的计量基于 CFS（Completely Fair Scheduler） 的调度周期。Kubernetes 通过 cAdvisor 采集每个容器的 CPU 使用时间（单位：纳秒），并转换为毫核（mCPU）或核时。

• Request（预留）：保证容器可获取的最小 CPU 资源，用于计价中的“预留成本”。
• Limit（上限）：容器可突发使用的最大 CPU，超出 Request 的部分按“弹性成本”计价。
• 实际使用：通过 container_cpu_usage_seconds_total 指标计算，用于按量付费场景。

3.2.2 计价模型公式

// 单容器 CPU 成本（单位：元）
CPU_Cost = (Request_Cores × 预留单价 × 运行时长)
         + (Max(实际使用核数 - Request_Cores, 0) × 弹性单价 × 运行时长)

// 示例：预留单价 0.5 元/核时，弹性单价 1.2 元/核时
// 容器 Request=1 Core，实际使用 1.8 Core，运行 2 小时
// 成本 = (1 × 0.5 × 2) + (0.8 × 1.2 × 2) = 1.0 + 1.92 = 2.92 元

3.3 内存计量与计价模型

3.3.1 计量原理

内存计量依赖 Memory cgroup 的 memory.usage_in_bytes 与 memory.working_set。Kubernetes 推荐使用 Working Set（活跃内存）作为实际使用量，因为它剔除了内核缓存等可回收部分，更贴近真实成本。

• 预留成本：按 Memory Request 的 GiB 时数计价。
• 突发成本：当实际 Working Set 超过 Request 时，超出部分按弹性单价计费。
• OOM 风险成本：若容器因内存不足被 OOM Kill，需额外计入“中断成本”或“SLA 赔偿成本”。

3.3.2 计价模型公式

// 单容器内存成本（单位：元）
Memory_Cost = (Request_GiB × 预留单价 × 运行时长)
            + (Max(WorkingSet_GiB - Request_GiB, 0) × 弹性单价 × 运行时长)

// 示例：预留单价 0.3 元/GiB时，弹性单价 0.8 元/GiB时
// 容器 Request=2 GiB，WorkingSet=3.5 GiB，运行 1 小时
// 成本 = (2 × 0.3 × 1) + (1.5 × 0.8 × 1) = 0.6 + 1.2 = 1.8 元

3.4 存储计量与计价模型

3.4.1 计量维度

存储成本分摊需区分以下三类场景：

1. 持久卷（PV）容量：按预置容量（GiB）与使用时长（月）计价，与是否写入数据无关。
2. IOPS / 吞吐量：云厂商通常按预置 IOPS 或吞吐量阶梯计价，高 IOPS 卷单价更高。
3. 快照与备份：按快照实际占用容量（增量）计费，通常为存储单价的 10%~30%。

3.4.2 计价模型公式

// 单 PVC 存储成本（单位：元/月）
Storage_Cost = (PV_Capacity_GiB × 容量单价)
             + (预置_IOPS × IOPS_单价)
             + (快照容量_GiB × 快照单价)

// 示例：容量单价 0.5 元/GiB月，IOPS 单价 0.01 元/IOPS月
// PV=100 GiB，预置 IOPS=3000，快照=20 GiB
// 成本 = (100 × 0.5) + (3000 × 0.01) + (20 × 0.15) = 50 + 30 + 3 = 83 元/月

3.5 网络流量计量与计价模型

3.5.1 计量方向与区域

网络流量成本具有明显的方向性与区域性：

• 入站流量（Ingress）：通常免费或极低单价。
• 出站流量（Egress）：主要计费对象，按 GB 计价。
• 跨可用区（Cross-AZ）：同 Region 内跨 AZ 流量通常有 0.01~0.02 元/GB 的附加费。
• 跨区域（Cross-Region）：单价最高，可达 0.5~1.0 元/GB。

3.5.2 计价模型公式

// 单 Namespace 网络成本（单位：元）
Network_Cost = (出站流量_GB × 出站单价)
             + (跨AZ流量_GB × 跨AZ附加单价)
             + (跨Region流量_GB × 跨Region单价)

// 示例：出站单价 0.8 元/GB，跨AZ附加 0.02 元/GB，跨Region 0.6 元/GB
// Namespace 出站 50 GB，跨AZ 10 GB，跨Region 5 GB
// 成本 = (50 × 0.8) + (10 × 0.02) + (5 × 0.6) = 40 + 0.2 + 3 = 43.2 元

3.6 核心指标分摊流程图

下图展示了从底层资源采集到最终 Namespace 级成本分摊的完整数据流，帮助理解各指标在架构中的流转路径。

3.7 多指标组合分摊策略

在实际项目部署中，单一指标往往无法公平反映成本。推荐采用加权组合分摊模型，将 CPU、内存、存储、网络按权重合并为一个“资源等价单位”。

3.7.1 组合分摊权重建议

3.7.2 组合成本计算公式

// 加权组合成本（单位：元）
Total_Cost = (CPU_Cost × CPU_Weight)
           + (Memory_Cost × Memory_Weight)
           + (Storage_Cost × Storage_Weight)
           + (Network_Cost × Network_Weight)

// 示例：计算密集型场景，各指标成本分别为 100、60、20、10 元
// 总成本 = (100 × 0.5) + (60 × 0.3) + (20 × 0.1) + (10 × 0.1)
//        = 50 + 18 + 2 + 1 = 71 元

3.8 计量与计价中的常见陷阱

• 陷阱一：忽略 Init 容器与 Sidecar 成本 —— Init 容器在启动期间消耗的 CPU/内存常被遗漏，Sidecar（如 Istio Proxy）的固定资源开销应分摊到所在 Pod 的 Owner。
• 陷阱二：存储快照按全量计费 —— 云厂商快照通常为增量备份，但首次快照为全量。若按全量分摊，会导致第一个月成本虚高。建议按实际增量容量分摊，或采用“月均快照成本”平滑处理。
• 陷阱三：网络流量忽略内网 Service 通信 —— 同 Namespace 内的 Pod 间流量通常免费，但跨 Namespace 的 Service 调用可能产生跨主机流量。若使用 Service Mesh，还需考虑 Sidecar 代理的额外网络开销。
• 陷阱四：CPU 弹性单价与预留单价倒挂 —— 在某些云厂商中，Spot 实例的弹性单价可能低于预留单价。此时应优先使用 Spot 实例处理弹性负载，避免按预留单价分摊弹性成本。