4. Kubernetes 资源模型：Pod、Deployment、StatefulSet、DaemonSet 的资源请求与限制对成本的影响

在 Kubernetes 集群中，资源请求（Request）与资源限制（Limit）是调度与计费的基石。不同工作负载类型（Pod、Deployment、StatefulSet、DaemonSet）对资源的声明方式直接影响集群的碎片率、装箱效率以及最终的成本分摊精度。本章将深入剖析这些资源模型对成本的影响机制。

4.1 资源请求与限制的核心概念

Kubernetes 通过 requests 和 limits 字段定义容器的资源约束。这两个字段在成本模型中扮演不同角色：

4.2 不同工作负载的资源声明模式

Pod、Deployment、StatefulSet、DaemonSet 在资源声明上存在本质差异，这些差异直接影响成本分摊的粒度与准确性。

4.2.1 Pod：原子单元的资源声明

Pod 是最小的调度单元，其资源声明直接定义在 containers[].resources 中。成本分摊时，Pod 的 requests 总和即为该 Pod 的预留成本。

apiVersion: v1
kind: Pod
metadata:
  name: cost-demo-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
      limits:
        cpu: "1"
        memory: "512Mi"

成本影响：Pod 级别的资源声明最直接，但缺乏弹性。如果 Pod 被重建（如因节点故障），其资源声明不变，成本分摊模型可以稳定追踪。

4.2.2 Deployment：无状态应用的资源模板

Deployment 通过 spec.template.spec.containers[].resources 定义 Pod 模板。所有由该 Deployment 管理的 Pod 副本共享同一资源模板。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cost-demo-deploy
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
        resources:
          requests:
            cpu: "1"
            memory: "512Mi"
          limits:
            cpu: "2"
            memory: "1Gi"

成本影响：

• 副本数变化：HPA 或手动扩缩容时，副本数变化直接导致总预留成本线性变化。成本分摊模型需实时追踪副本数。
• 滚动更新：更新期间新旧 Pod 共存，临时增加资源占用，成本分摊需考虑重叠期。

4.2.3 StatefulSet：有状态应用的资源声明

StatefulSet 与 Deployment 类似，但每个 Pod 拥有稳定的网络标识和持久化存储。资源声明同样定义在 Pod 模板中。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: cost-demo-stateful
spec:
  serviceName: "db"
  replicas: 3
  template:
    spec:
      containers:
      - name: db
        resources:
          requests:
            cpu: "2"
            memory: "4Gi"
          limits:
            cpu: "4"
            memory: "8Gi"

成本影响：

• 存储成本关联：StatefulSet 通常绑定 PVC，成本分摊模型需将存储成本与 Pod 资源成本合并计算。
• 有序调度：StatefulSet 的 Pod 按序创建和删除，资源预留的波动模式与 Deployment 不同，需在分摊周期内精确统计。

4.2.4 DaemonSet：节点级守护进程的资源声明

DaemonSet 确保每个节点（或符合条件的节点）上运行一个 Pod。其资源声明同样定义在 Pod 模板中，但副本数由节点数量决定。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: cost-demo-daemon
spec:
  template:
    spec:
      containers:
      - name: agent
        resources:
          requests:
            cpu: "200m"
            memory: "128Mi"
          limits:
            cpu: "500m"
            memory: "256Mi"

成本影响：

• 节点数量驱动：DaemonSet 的总资源消耗随集群节点数线性增长。成本分摊时，DaemonSet 的成本应被视为集群基础设施成本，按节点或按其他工作负载的 Pod 数量进行二次分摊。
• 资源碎片：DaemonSet 的 Pod 通常占用少量资源，但会占据每个节点的资源碎片，影响其他工作负载的装箱效率。

4.3 资源模型对成本分摊的直接影响

下图展示了不同工作负载类型在资源预留与成本分摊上的差异：

4.4 资源请求与限制对成本的具体影响

4.4.1 请求值过高导致的资源浪费

当 requests 设置远高于实际使用量时，集群会预留大量闲置资源，导致：

• 装箱效率下降：节点可调度的 Pod 数量减少，需要更多节点来承载工作负载。
• 成本虚高：按 requests 分摊时，团队为未使用的资源付费。

4.4.2 限制值过低导致的 OOMKill 与稳定性成本

当 limits 设置过低时，容器可能因内存不足被 OOMKill，导致：

• Pod 重启：增加调度开销和延迟，影响服务质量。
• 隐性成本：重启期间的资源占用、日志收集、监控告警等间接成本。

4.4.3 资源碎片与装箱优化

不同工作负载的资源声明组合会产生节点资源碎片。下图展示了资源碎片对成本的影响：

4.5 成本分摊模型中的资源映射策略

在实际工程中，成本分摊模型需要将不同工作负载的资源声明映射到统一的成本度量单位。以下是推荐的映射策略：

4.6 实践建议：优化资源声明以降低成本

1. 基于历史数据调整 requests：使用 VPA（Vertical Pod Autoscaler）或监控工具分析容器实际资源使用量，将 requests 设置为 P50~P75 分位数，避免过度预留。
2. 合理设置 limits：limits 应至少等于 requests，建议设置为 requests 的 1.5~2 倍，以应对突发流量，同时防止资源滥用。
3. DaemonSet 资源优化：DaemonSet 的 requests 应尽可能小，避免占用过多节点资源碎片。考虑使用 resourceQuota 限制 DaemonSet 的总资源占用。
4. StatefulSet 存储成本分摊：将 PVC 的存储成本与 Pod 资源成本合并，按 StatefulSet 的命名空间或标签进行分摊。
5. 定期审计资源声明：使用成本分摊工具生成资源浪费报告，识别 requests 设置过高的工作负载，推动团队优化。