3. Kubernetes 资源模型与成本映射：Pod/Node/Namespace 资源模型、Request/Limit 与成本分摊、资源利用率基准线

在 FinOps 驱动的云原生性能调优中，Kubernetes 资源模型是连接技术指标与财务成本的桥梁。本章将深入剖析 Pod、Node、Namespace 三级资源模型，建立 Request/Limit 到实际账单的映射关系，并定义资源利用率基准线，为后续的成本优化提供量化依据。

3.1 三级资源模型：Pod → Node → Namespace

Kubernetes 的资源管理从下至上分为三个层级，每一层都承载着不同的成本语义：

3.2 Request / Limit 与成本分摊模型

Request 和 Limit 是 Kubernetes 资源调度的核心参数，也是成本分摊的直接依据。错误的配置会导致成本黑洞或性能瓶颈。

3.2.1 核心概念对比

3.2.2 成本分摊公式

在实际 FinOps 实践中，推荐使用 Request 加权分摊 作为默认模型，因为它与调度决策直接挂钩，且不受瞬时突发影响。

# 单 Pod 每小时成本分摊
Pod_Cost = Node_Hourly_Cost × (Pod_Request_CPU / Node_Allocatable_CPU)

# 示例：m5.xlarge 节点 $0.192/h，Pod Request 1 CPU，Node Allocatable 3.7 CPU
Pod_Cost = 0.192 × (1.0 / 3.7) ≈ $0.0519/h

3.3 资源利用率基准线

基准线是判断资源是否“健康”的标尺。FinOps 要求同时建立 性能基准线 和 成本基准线，两者缺一不可。

3.3.1 核心指标定义

3.3.2 基准线建立流程

1. 数据采集：通过 Prometheus / Metrics Server 采集 7 天以上的 Pod 和 Node 粒度的 CPU/Memory 实际使用量。
2. 分位数计算：取 P50（典型负载）、P95（峰值负载）、P99（极限负载）作为参考。
3. Request 校准：将 Request 设置为 P95 实际使用量的 1.1x – 1.2x，兼顾稳定性和成本。
4. Limit 设置：CPU Limit 可设为 Request 的 1.5x – 2x（允许突发）；Memory Limit 建议等于 Request（禁止超卖）。
5. 持续监控：每周生成利用率报告，标记偏离基准线的 Pod 和 Namespace。

3.4 资源模型与成本映射架构

下图展示了从 Pod 资源请求到最终云账单的完整映射链路，以及 FinOps 在各环节的干预点。

3.5 实战：Namespace 级成本分摊示例

假设一个集群包含 3 个 Namespace，使用 Request 加权分摊模型，结果如下：

3.6 资源利用率基准线设定案例

以下是一个实际生产集群的基准线设定示例，基于 7 天 P95 数据：

# 基准线配置文件示例 (YAML 风格)
namespace: production
baseline:
  cpu:
    target_utilization: 70%          # 目标利用率
    request_overhead: 1.15           # Request = P95 × 1.15
    limit_overhead: 1.8              # Limit = Request × 1.8
  memory:
    target_utilization: 65%
    request_overhead: 1.10
    limit_overhead: 1.0              # Memory Limit = Request (禁止超卖)
  node:
    target_packing_ratio: 75%        # 目标装箱率
    min_packing_ratio: 50%           # 低于此值触发缩容
    max_packing_ratio: 90%           # 高于此值触发扩容