4. 成本分摊基础：云原生环境下的成本分摊模型

在云原生架构中，资源由多个团队、应用或环境共享。没有清晰的分摊模型，成本将变成一笔“糊涂账”，导致预算失控、优化无门。本章从 FinOps 框架出发，建立可落地的分摊粒度与标签策略。

4.1 FinOps 成本分摊模型

FinOps 将云成本管理分为三个持续阶段：可见（Inform）、优化（Optimize）、运营（Operate）。分摊模型是“可见”阶段的核心输出，它回答“谁花了多少钱”。

4.2 分摊粒度：从集群到容器

分摊粒度决定了成本数据的可操作性。粒度过粗（如按集群）无法定位浪费；粒度过细（如按函数调用）则带来巨大的计量开销。云原生环境下推荐以下粒度层次：

1. 集群/命名空间 —— 基础设施底座，适合平台团队预算。
2. 工作负载（Deployment/StatefulSet） —— 应用级成本，适合服务 Owner。
3. Pod —— 最小调度单元，适合弹性伸缩分析。
4. 容器 —— 最细粒度，适合 Sidecar 与业务容器分离计费。

4.3 标签策略：成本分摊的“锚点”

标签（Labels）是 Kubernetes 中实现成本分摊的核心机制。一个良好的标签策略应遵循以下原则：

• 强制性：通过 OPA/Gatekeeper 或 Kyverno 强制所有工作负载必须携带成本标签。
• 标准化：统一标签键命名，例如 cost.team、cost.env、cost.service。
• 层次化：支持从团队到子服务的多级聚合。
• 不可变：已分摊的历史成本不应因标签变更而重算，建议使用时间戳快照。

# 示例：为 Deployment 添加成本标签
apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-service
  labels:
    cost.team: payment
    cost.env: production
    cost.service: checkout
    cost.sidecar: envoy
spec:
  template:
    metadata:
      labels:
        cost.team: payment
        cost.env: production
        cost.service: checkout
        cost.sidecar: envoy
    spec:
      containers:
      - name: envoy-sidecar
        image: envoyproxy/envoy:v1.28
        resources:
          requests:
            cpu: 500m
            memory: 256Mi
      - name: app
        image: checkout:1.2.3
        resources:
          requests:
            cpu: 2
            memory: 1Gi

4.4 成本分摊与 Envoy 代理的协同

Envoy Sidecar 作为网格数据平面，其资源消耗需要从业务成本中剥离。推荐以下协同策略：

• 标签分离：使用 cost.sidecar: envoy 标签标记所有 Envoy 容器，分摊工具据此将代理成本归入“基础设施”预算。
• 比例因子：如果无法打标，按 Envoy 容器请求量占 Pod 总请求量的比例拆分 Pod 成本。
• 同步窗口开销：GitOps 同步期间，Envoy 可能因配置热加载产生额外 CPU 峰值。这部分开销应计入“变更成本”，通过标签 cost.activity: sync 单独追踪。

4.5 落地检查清单

• 标签覆盖率：所有命名空间和工作负载是否已打标？使用 kubectl get pods --all-namespaces -o json | jq '.items[].metadata.labels' 审计。
• 分摊工具：是否部署了 OpenCost、Kubecost 或云厂商原生成本管理工具？
• Envoy 成本基线：是否已测量 Sidecar 的 CPU/内存基线，并设置告警阈值？
• 同步窗口成本：GitOps 同步期间的成本峰值是否已记录？是否纳入变更审批流程？