3. 云原生资源模型（一）：Pod、Container、Namespace的资源抽象与计量

在云原生成本分摊体系中，资源模型是计量的基石。Kubernetes 通过 Pod、Container、Namespace 三层抽象，将物理或虚拟机的原始资源（CPU、内存、存储、网络）转化为可调度、可隔离、可归属的逻辑单元。理解这三层的资源定义与计量方式，是实现精准成本分摊的前提。

3.1 资源抽象的三层结构

Kubernetes 的资源模型采用分层设计，每一层解决不同的职责：

3.2 Pod 的资源聚合模型

Pod 是 Kubernetes 中可调度的最小单位。一个 Pod 可以包含一个或多个 Container。在资源计量上，Pod 的资源请求（Requests）和限制（Limits）是其所有 Container 对应值的总和。

以下是一个包含两个容器的 Pod 资源定义示例：

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
  namespace: production
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "256Mi"
        cpu: "500m"
      limits:
        memory: "512Mi"
        cpu: "1"
  - name: sidecar
    image: envoyproxy/envoy
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "256Mi"
        cpu: "500m"

该 Pod 的聚合资源计量为：

• CPU Requests: 500m + 250m = 750m
• Memory Requests: 256Mi + 128Mi = 384Mi
• CPU Limits: 1 + 500m = 1500m
• Memory Limits: 512Mi + 256Mi = 768Mi

3.3 Namespace 的资源隔离与配额计量

Namespace 是 Kubernetes 实现多租户隔离的核心机制。在成本分摊场景中，Namespace 通常映射为业务部门、项目或环境（如 dev、staging、prod）。通过 ResourceQuota 和 LimitRange，平台团队可以控制每个 Namespace 的资源消耗上限。

ResourceQuota 示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: production-quota
  namespace: production
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    persistentvolumeclaims: "10"
    pods: "50"

Namespace 级别的计量数据是成本分摊的第一级聚合。通过汇总 Namespace 下所有 Pod 的资源使用量，可以快速得到该业务单元的总资源消耗，再结合云厂商的单价，即可计算出该 Namespace 的原始成本。

3.4 三层资源计量关系图

下图展示了从 Container 到 Namespace 的资源计量聚合路径：

3.5 资源计量中的关键指标

在云原生成本分摊中，以下四个指标是计量与分摊的核心：

3.6 从资源模型到成本分摊的映射

理解了三层资源模型后，我们可以建立从资源到成本的映射关系：

1. 数据采集层：通过 Metrics Server、Prometheus 或 cAdvisor 采集每个 Container 的 CPU/Memory Requests、Limits 和实际 Usage。
2. 聚合层：按 Pod 聚合容器数据，再按 Namespace 聚合 Pod 数据，形成多级资源消耗视图。
3. 定价层：将云厂商的单价（如 $0.10/vCPU/小时、$0.01/GiB/小时）与资源消耗量相乘，得到原始成本。
4. 分摊层：根据业务归属（Namespace、Label、Annotation）将原始成本分摊到对应的成本中心。

下图展示了从资源计量到成本分摊的完整链路：

3.7 常见计量误区与避坑

• 误区一：只采集 Usage 忽略 Requests。 集群的固定成本（如节点租金）由 Requests 决定，只按 Usage 分摊会导致“预留资源”的成本无人承担。
• 误区二：Pod 级别直接分摊，忽略容器角色。 如 3.2 节所述，sidecar 容器的成本应单独归入基础设施或平台成本，而非业务成本。
• 误区三：Namespace 作为唯一分摊维度。 当多个业务共享同一个 Namespace 时，应结合 Label 或 Annotation 进行二次拆分。
• 误区四：忽略 Init Container 和 Ephemeral Container。 这些临时容器的资源消耗虽然短暂，但在批量任务或 CI/CD 场景中可能占据显著成本。