2. Kubernetes 成本构成分析：计算资源、存储资源与网络资源的成本模型
在构建云原生成本分摊模型之前，必须对 Kubernetes 集群中可计费的基础资源进行拆解。Kubernetes 本身不产生直接费用，其成本来源于底层基础设施的消耗。本章将计算资源、存储资源和网络资源三大类进行成本模型定义，为后续的分摊引擎设计提供量化依据。
2.1 计算资源成本模型：CPU 与内存
计算资源是 Kubernetes 集群中占比最高的成本项，通常占总成本的 60%~80%。其成本模型围绕 CPU 和 内存 两个维度展开，核心公式为：
Pod 计算成本 = (CPU 请求量 × CPU 单价) + (内存请求量 × 内存单价)在实际工程中，单价并非简单的云厂商标价，而是需要根据集群实际利用率进行加权调整。下表展示了两种主流的计价策略：
| 计价策略 | CPU 单价计算方式 | 内存单价计算方式 | 适用场景 |
|---|---|---|---|
| 按节点均摊 | 节点总成本 / 节点总 CPU 核数 | 节点总成本 / 节点总内存 GB | 节点规格统一、利用率均衡 |
| 按资源比例加权 | 节点总成本 × (CPU 核数占比) | 节点总成本 × (内存 GB 占比) | 异构节点、CPU/内存配比差异大 |
工程建议：推荐使用“按资源比例加权”策略。例如，一个 8C32G 的节点月成本为 2000 元，则 CPU 权重为 8/(8+32×0.25)=0.5，内存权重为 0.5（假设 CPU:内存价格比为 1:0.25）。这种模型能更公平地反映异构节点的实际消耗。
以下 SVG 展示了从节点成本到 Pod 成本的分层计算流程：
2.2 存储资源成本模型：PV 与临时存储
存储成本在 Kubernetes 中分为持久化存储（PersistentVolume）和临时存储（Ephemeral Storage）两类。两者的计费模型差异显著：
- 持久化存储（PV）：按 容量（GB）× 时长（小时） 计费，通常与存储类型（SSD/HDD）和 IOPS 性能相关。成本归属明确，直接挂载到特定 Namespace 或 Pod。
- 临时存储（Ephemeral）：使用节点本地磁盘（如 Docker 层、emptyDir），成本已隐含在节点计算资源中。需要按 Pod 实际使用量 或 emptyDir 限制量 进行二次分摊。
| 存储类型 | 计费维度 | 成本归属难度 | 推荐分摊方式 |
|---|---|---|---|
| PV（SSD/HDD） | 容量 × 时长 | 低（直接关联 PVC） | 按 PVC 的 storage 字段直接归属到 Namespace |
| PV（快照/备份） | 快照大小 × 保留天数 | 中（需关联源 PVC） | 按源 PVC 的 Namespace 比例分摊 |
| 临时存储（emptyDir） | 节点磁盘空间 | 高（共享节点） | 按 Pod 的 emptyDir 限制量或实际使用量加权 |
| 临时存储（容器层） | 镜像层 + 容器日志 | 高（难以追踪） | 按 Pod 的 CPU/内存请求量比例分摊 |
常见陷阱：临时存储成本容易被忽略。当节点磁盘压力高时，临时存储的隐性成本可能超过 PV 成本。建议在成本模型中为临时存储设置一个“节点磁盘预留系数”（如 10%~20%），从节点总成本中扣除后，再按 Pod 资源请求量分摊。
以下 SVG 展示了存储成本从节点磁盘到 Pod 的分摊路径：
2.3 网络资源成本模型：流量与负载均衡
网络成本在 Kubernetes 中通常被低估，但在跨可用区（AZ）或跨地域（Region）场景下可能成为主要成本项。网络成本模型包含两个核心子项：
- 流量成本：包括入站流量（通常免费）、出站流量（按 GB 计费）以及跨 AZ/Region 的流量（价格更高）。在 Kubernetes 中，流量成本需要按 Service/Ingress 的出口流量 或 Pod 的网络接口统计 进行分摊。
- 负载均衡成本：云厂商的负载均衡器（如 AWS ALB、GCP HTTP LB）通常按 每小时 + 每 LCU/数据单元 计费。在 Kubernetes 中，每个 Service Type=LoadBalancer 或 Ingress 都会产生独立的负载均衡器成本。
| 网络资源项 | 计费单位 | Kubernetes 关联对象 | 分摊粒度 |
|---|---|---|---|
| 出站流量（Internet） | GB | Service/Ingress | 按 Service 的出口流量比例 |
| 跨 AZ 流量 | GB | Pod 间通信 | 按 Namespace 的跨 AZ 流量统计 |
| 负载均衡器（LB） | 小时 + LCU | Service/Ingress | 按 LB 关联的 Namespace 直接归属 |
| NAT 网关 | 小时 + GB | 出站流量 | 按 Pod 的出站流量比例 |
工程实践：在 FinOps 平台中，网络成本分摊通常采用“标签追踪 + 流量采样”的方式。例如，在 Istio 或 Cilium 中启用流量监控，通过 eBPF 或 sidecar 代理采集每个 Pod 的出口流量字节数，然后按 Namespace 或 Deployment 聚合，再乘以云厂商的流量单价。
以下 SVG 展示了网络成本从云厂商账单到 Kubernetes 工作负载的映射关系：
2.4 三类资源的成本模型对比总结
将计算、存储、网络三类资源的成本模型进行横向对比，有助于在 FinOps 平台中统一设计分摊引擎：
| 维度 | 计算资源 | 存储资源 | 网络资源 |
|---|---|---|---|
| 成本占比 | 60%~80% | 10%~25% | 5%~15% |
| 计费粒度 | Pod 请求量（requests） | PV 容量 / 临时存储使用量 | LB 实例 + 流量 GB |
| 分摊难度 | 中（需处理超卖与空闲） | 低（PV 直接归属） | 高（流量追踪复杂） |
| 核心数据源 | Metrics Server / Prometheus | PV/PVC API + 云厂商账单 | 云厂商账单 + 网络监控（eBPF/Istio） |
| 推荐分摊策略 | 按资源比例加权 | PV 直接归属 + 临时按比例 | LB 直接归属 + 流量按标签 |
下一步工程提示：在明确了三类资源的成本模型后，下一章将进入“成本分摊引擎”的设计阶段。你需要为每种资源定义数据采集器（Collector）、计价器（Pricer）和分摊器（Allocator）三个核心组件。建议在代码实现中为每类资源建立独立的接口，便于后续扩展 GPU、FPGA 等异构计算资源的成本模型。