2. Kubernetes 资源模型：Pod、Node、Namespace、Cluster 的资源抽象，以及资源请求(Request)与限制(Limit)对成本的影响
在云原生成本分摊模型中，Kubernetes 的资源抽象层是成本核算的基石。理解 Pod、Node、Namespace 和 Cluster 的层级关系，以及 Request 与 Limit 的语义差异，是构建精准成本模型的前提。错误的资源抽象理解会导致成本数据失真，进而影响容量规划与预算决策。
2.1 四层资源抽象模型
Kubernetes 的资源管理从物理/虚拟机的硬件资源出发，向上逐层抽象为 Cluster、Node、Namespace 和 Pod。每一层都承载着不同的成本分摊粒度：
| 层级 | 资源抽象 | 成本分摊粒度 | 典型分摊对象 |
|---|---|---|---|
| Cluster | 一组 Node 的集合，共享控制平面与网络 | 基础设施总成本（IaaS 账单） | 集群整体、共享组件（etcd、DNS） |
| Node | 一台物理机或虚拟机，提供 CPU、内存、存储 | 节点级固定成本（实例费用） | 节点规格、预留实例、Spot 实例 |
| Namespace | 虚拟集群内的逻辑隔离单元 | 团队/项目级成本聚合 | 业务线、环境（prod/staging） |
| Pod | 最小调度单元，包含一个或多个容器 | 最细粒度的资源消耗单元 | 微服务、Job、DaemonSet |
关键认知：成本分摊的精度取决于你选择哪一层作为“锚点”。Pod 级分摊最精确但计算开销大；Namespace 级分摊适合团队预算管理；Node 级分摊常用于混合计费场景。
2.2 资源请求（Request）与限制（Limit）的成本语义
Request 和 Limit 是 Kubernetes 资源模型中最核心的两个参数，它们直接影响调度决策和成本计算。许多成本偏差的根源在于混淆了“预留”与“上限”的成本含义。
- Request（请求）：容器启动时向调度器承诺的最小资源保证。调度器依据所有 Pod 的 Request 总和来决定能否将 Pod 调度到某个 Node 上。在成本模型中，Request 代表预留成本——无论 Pod 实际使用多少资源，这部分资源已被“锁定”。
- Limit（限制）：容器运行时允许使用的资源上限。当容器试图使用超过 Limit 的资源时，会被 throttled（CPU）或 OOMKilled（内存）。Limit 不代表实际消耗，但在某些成本模型中会被用作最大可能成本的估算依据。
| 参数 | 调度影响 | 运行时影响 | 成本模型含义 |
|---|---|---|---|
| Request | 决定 Pod 能否调度到 Node | 保证最小资源可用 | 预留成本（已支付但可能未使用） |
| Limit | 不影响调度（仅 QoS 分类） | 限制突发资源使用 | 最大可能成本（风险敞口） |
| 实际使用量 | 不参与调度决策 | 动态变化，受业务负载影响 | 实际消耗成本（按需计费） |
成本模型选择建议：对于固定成本分摊（如包年包月节点），优先使用 Request 作为分摊权重；对于弹性成本（如 Spot 实例、按需实例），建议使用 实际使用量 或 Request + 利用率系数 的组合。
2.3 Request 与 Limit 对成本分摊的直接影响
以下场景展示了 Request/Limit 配置不当如何导致成本分摊失真：
- 场景一：Request 远大于实际使用 —— 团队 A 为所有容器设置 4 核 CPU Request，但实际平均使用仅 0.5 核。按 Request 分摊成本时，团队 A 承担了 4 倍于实际消耗的成本，导致其他团队“补贴”了闲置资源。
- 场景二：Limit 远大于 Request —— 团队 B 设置 Request 0.5 核、Limit 8 核。虽然预留成本低，但突发时可能抢占 Node 资源，影响同节点其他 Pod 的稳定性。成本模型若仅基于 Request，会低估团队 B 的资源风险敞口。
- 场景三：未设置 Request 和 Limit —— 容器运行在 BestEffort QoS 下，无资源保证。成本模型无法准确归因，通常只能按 Namespace 或 Node 平均分摊，精度极低。
避坑指南：不要将 Limit 等同于“成本上限”。Limit 仅控制运行时行为，不参与调度计费。在成本分摊模型中，Request 是更稳定的分摊基准，而 Limit 应作为“超额风险”的辅助指标。
2.4 资源抽象与成本分摊的映射关系
下图展示了从 Cluster 到 Pod 的资源抽象层级，以及每一层对应的成本分摊关键路径：
2.5 成本分摊模型中的 Request 与 Limit 计算示例
假设一个 Node 的总成本为 $1000/月，其上运行了 3 个 Pod，资源参数如下：
| Pod | CPU Request | CPU Limit | CPU 实际使用（平均） | 内存 Request | 内存 Limit |
|---|---|---|---|---|---|
| Pod-A | 2 核 | 4 核 | 1.5 核 | 4 Gi | 8 Gi |
| Pod-B | 1 核 | 2 核 | 0.8 核 | 2 Gi | 4 Gi |
| Pod-C | 3 核 | 6 核 | 2.0 核 | 6 Gi | 12 Gi |
三种分摊策略的结果对比：
| 分摊策略 | Pod-A 成本 | Pod-B 成本 | Pod-C 成本 | 特点 |
|---|---|---|---|---|
| 按 Request（CPU+内存） | $333.33 | $166.67 | $500.00 | 稳定、可预测，适合预算控制 |
| 按实际使用（CPU+内存） | $279.07 | $148.84 | $572.09 | 公平、反映真实消耗，但波动大 |
| 按 Limit（CPU+内存） | $333.33 | $166.67 | $500.00 | 与 Request 相同（本例巧合），但风险不同 |
结论：在本例中，按 Request 和按 Limit 的分摊结果相同，但 Pod-A 的 Limit 是 Request 的 2 倍，意味着它可能突发占用更多资源。成本模型若仅基于 Request，会忽略这种“突发风险”。建议在成本报告中同时展示 Request 成本 和 Limit 成本，以提供完整的资源视图。
2.6 资源抽象与成本追踪的关键路径
以下流程图展示了从 Pod 资源声明到成本分摊的完整关键路径：
2.7 最佳实践：Request 与 Limit 的成本优化建议
- 设置合理的 Request 值：基于历史监控数据（P50 或 P75 分位）设置 Request，避免过度预留。使用 VPA（Vertical Pod Autoscaler）或成本分析工具推荐 Request 值。
- Limit 不应远大于 Request：建议 Limit/Request 比例不超过 2:1（CPU）和 1.5:1（内存）。过大的 Limit 会增加资源争抢风险，且成本模型难以准确评估。
- 优先使用 Guaranteed QoS：当 Request = Limit 时，Pod 获得 Guaranteed QoS，调度确定性最高，成本分摊最清晰。对于关键业务 Pod，建议统一配置。
- 定期审计未设置 Request/Limit 的 Pod：BestEffort Pod 无法参与精确成本分摊，应通过准入控制器（如 OPA/Kyverno）强制要求设置。
- 成本报告同时展示 Request 和实际使用：在成本仪表盘中，同时展示“预留成本”（基于 Request）和“效率指标”（实际使用/Request），帮助团队识别资源浪费。
样本抽检建议：在成本分摊模型上线初期，建议按 Namespace 随机抽检 10% 的 Pod，对比 Request 成本与实际使用成本的偏差。如果偏差超过 30%，说明 Request 配置需要优化，否则成本分摊结果可能误导预算决策。