4. 云原生资源模型（二）：Node、Cluster、PV/PVC 的资源抽象与计量
在 Kubernetes 集群中，Node、Cluster 以及持久化存储（PV/PVC）构成了除 Pod 与 Container 之外最核心的资源抽象层。理解这三类资源的计量口径与成本分摊逻辑，是实现 FinOps 精细化管理的关键前提。
4.1 Node 资源抽象与计量模型
Node 是集群中的计算节点（物理机或虚拟机），其资源总量决定了集群的容量上限。在成本分摊中，Node 通常作为“资源池”而非直接分摊单元，但它的计量数据是上层分摊的基础。
| 资源维度 | 计量单位 | 说明 |
|---|---|---|
| CPU | Core（核） | Node 上可分配的 CPU 总量，通常减去 kube-reserved 与 system-reserved |
| Memory | GiB（吉字节） | Node 上可分配的内存总量，同样需要扣除系统预留 |
| Ephemeral Storage | GiB | 本地临时存储，用于 emptyDir、容器日志等 |
| Node 单价 | 元/小时 或 元/月 | 云厂商实例定价或内部成本核算价格 |
关键概念：Node 的“可分配资源”不等于“已使用资源”。在成本分摊时，通常采用“已分配资源”（即 Pod 的 Request 总和）作为分摊依据，而非实际使用量，以鼓励用户合理设置资源请求。
4.2 Cluster 资源抽象与计量模型
Cluster 是多个 Node 组成的逻辑集合，其成本包括所有 Node 的成本加上集群管理服务费用（如 EKS/AKS/GKE 的控制面费用）。Cluster 层面的计量主要用于整体成本核算和跨集群成本对比。
- 集群总成本 = Σ(Node 成本) + 控制面成本 + 附加组件成本（如 Ingress Controller、监控组件）
- 集群资源总量 = Σ(Node 可分配资源)
- 集群资源利用率 = Σ(Pod 实际使用量) / Σ(Node 可分配资源)
实践建议：在 FinOps 实践中，Cluster 通常作为“成本聚合层”，不直接向业务分摊，而是将成本按 Namespace、Label、Service 等维度下钻到工作负载。
4.3 PV/PVC 资源抽象与计量模型
持久化存储（PV/PVC）是云原生环境中成本占比最高的资源之一，其计量模型与计算资源有显著差异。
| 资源维度 | 计量单位 | 说明 |
|---|---|---|
| 存储容量 | GiB | PV 的声明容量，通常按 PVC 的 Request 计量 |
| 存储类型 | SSD / HDD / 通用型 | 不同存储类型单价差异巨大 |
| IOPS | 次/秒 | 部分云厂商按预置 IOPS 计费 |
| 吞吐量 | MB/s | 部分高性能存储按吞吐量计费 |
| 快照/备份 | GiB / 次数 | 快照空间与备份频率产生的额外成本 |
常见误区：PV 的容量计量不等于实际使用量。很多团队按 PVC 的 Request 容量分摊成本，但实际存储使用量可能远低于声明容量，导致成本分摊失真。建议结合存储后端的使用量监控数据进行校准。
4.4 资源抽象与计量的分层架构
下图展示了 Node、Cluster、PV/PVC 在资源抽象与计量中的分层关系，以及成本数据如何从底层向上聚合。
4.5 PV/PVC 成本分摊的两种模式
在实际 FinOps 实践中，PV/PVC 的成本分摊通常采用以下两种模式：
| 分摊模式 | 分摊依据 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|---|
| 声明容量分摊 | PVC 的 Request 容量 × 存储单价 | 存储容量固定、使用量稳定的场景 | 计算简单，易于预测 | 可能高估成本，无法反映实际使用 |
| 实际使用量分摊 | 存储后端监控的实际使用量 × 存储单价 | 存储容量弹性、使用量波动大的场景 | 成本分摊更准确 | 需要额外监控工具，计算复杂 |
最佳实践：建议采用“声明容量分摊”作为默认模式，同时定期（如每月）使用实际使用量数据进行校准，对偏差超过 20% 的 PVC 进行标记和调整。
4.6 Node 与 PV/PVC 的计量差异对比
下表总结了 Node 与 PV/PVC 在资源计量中的核心差异：
| 对比维度 | Node（计算资源） | PV/PVC（存储资源） |
|---|---|---|
| 资源类型 | 可抢占、可超卖 | 独占、不可超卖 |
| 计量粒度 | CPU 核、内存 GiB | 存储容量 GiB、IOPS、吞吐量 |
| 分摊依据 | Pod Request 或实际使用量 | PVC Request 或实际使用量 |
| 成本波动 | 随 Pod 调度变化 | 相对稳定，随 PVC 创建/删除变化 |
| 监控复杂度 | 低（Metrics Server 即可） | 高（需对接存储后端 API） |
4.7 实践案例：多团队共享集群的成本拆分
假设一个集群包含 3 个 Node，每个 Node 单价为 100 元/小时，集群控制面成本为 50 元/小时。集群中有两个团队（Team A 和 Team B）运行工作负载，并使用了不同的 PVC。
- 计算集群总成本：3 × 100 + 50 = 350 元/小时
- 统计各团队资源 Request：
- Team A：CPU Request 8 核，Memory Request 32 GiB，PVC 容量 100 GiB
- Team B：CPU Request 12 核，Memory Request 48 GiB，PVC 容量 200 GiB
- 按比例分摊：
- Team A 计算成本占比：8/(8+12) = 40%，即 350 × 40% = 140 元/小时
- Team B 计算成本占比：12/(8+12) = 60%，即 350 × 60% = 210 元/小时
- 存储成本单独按 PVC 容量分摊：假设存储单价 0.1 元/GiB/小时
- Team A 存储成本：100 × 0.1 = 10 元/小时
- Team B 存储成本：200 × 0.1 = 20 元/小时
- 最终成本：
- Team A：140 + 10 = 150 元/小时
- Team B：210 + 20 = 230 元/小时
扩展思考：如果 Team A 的 Pod 实际只使用了 50% 的 Request 资源，而 Team B 使用了 90%，是否应该按实际使用量重新分摊？这取决于组织的 FinOps 成熟度——初期建议按 Request 分摊，成熟期可引入实际使用量校准。
4.8 资源计量与成本分摊的自动化工具链
下图展示了从资源计量到成本分摊的自动化工具链架构，帮助团队实现持续的成本可见性。
4.9 本章小结
- Node 是计算资源的物理/虚拟载体，其可分配资源是成本分摊的基础池。
- Cluster 是成本聚合层，包含所有 Node 成本与控制面成本。
- PV/PVC 是存储资源的抽象，其计量维度包括容量、IOPS、吞吐量等，分摊模式需根据场景选择。
- 资源计量与成本分摊需要建立自动化工具链，实现从数据采集到反馈优化的闭环。
- 推荐采用“按 Request 分摊为主，实际使用量校准为辅”的策略，平衡准确性与实施复杂度。