3. Resource Quota 核心指标:CPU、内存、存储、Pod 数量、PVC 数量等关键配额指标

Resource Quota 是 Kubernetes 中实现多租户资源隔离与成本分摊的核心原语。在云原生 FinOps 实践中,准确理解 Quota 所涵盖的各类指标,是构建成本模型、设置告警阈值以及进行容量规划的基础。本章将逐一拆解这些关键配额指标,并分析其在成本分摊场景下的实际意义。

3.1 核心指标全景图

Kubernetes 的 Resource Quota 支持对计算资源、存储资源和对象数量进行三层维度的限制。以下 SVG 展示了这三大类指标及其在集群中的层级关系:

Resource Quota 核心指标分类与层级 ResourceQuota 对象 计算资源 存储资源 对象数量 requests.cpu requests.memory limits.cpu limits.memory requests.storage persistentvolumeclaims storage-class 细分 pods services configmaps secrets 成本分摊关键点 • requests 指标决定资源预留成本,limits 指标决定资源上限成本 • PVC 数量与存储容量直接关联存储成本,需按 StorageClass 细分 • Pod 数量影响调度密度和 IP 资源消耗,是成本模型的基础单元

3.2 计算资源指标详解

计算资源是成本分摊中最核心的维度,直接决定了集群的算力成本。Kubernetes 通过 requests 和 limits 两个层面来管理 CPU 和内存。

指标名称 单位 语义 成本分摊作用
requests.cpu cores(核) Pod 启动时保证的最小 CPU 资源 作为资源预留成本的基础计量单位
requests.memory bytes(字节) Pod 启动时保证的最小内存资源 决定内存预留成本,通常按 GB 计费
limits.cpu cores(核) Pod 可使用的 CPU 上限 用于超分场景下的成本上限控制
limits.memory bytes(字节) Pod 可使用的内存上限 防止内存泄漏导致成本失控
FinOps 实践建议:在成本分摊模型中,优先使用 requests 作为成本计算基准,因为它反映了资源预留的真实承诺。对于超卖场景,可结合 limits 与实际使用量(通过 Metrics Server 采集)进行加权分摊。

3.3 存储资源指标详解

存储成本在云原生环境中往往被低估。Resource Quota 提供了对存储容量和 PVC 数量的双重控制。

  • requests.storage:限制所有 PVC 请求的总存储容量,单位是 bytes。这是存储成本分摊的直接依据。
  • persistentvolumeclaims:限制命名空间内允许创建的 PVC 总数。每个 PVC 即使未使用也会产生管理开销和潜在的云服务费用。
  • storage-class 细分:通过 <storage-class-name>.storageclass.storage.k8s.io/requests.storage 和 <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims 实现按存储类型(如 SSD、HDD、归档)的精细化配额控制。
成本模型示例:假设集群使用 AWS EBS,gp3(SSD)单价为 $0.08/GB/月,sc1(HDD)单价为 $0.025/GB/月。通过 StorageClass 级别的 Quota 指标,可以分别统计两个命名空间的存储成本:
# 命名空间 A 的 Quota 配置
apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: team-a
spec:
  hard:
    gp3.storageclass.storage.k8s.io/requests.storage: "500Gi"
    sc1.storageclass.storage.k8s.io/requests.storage: "1Ti"
    gp3.storageclass.storage.k8s.io/persistentvolumeclaims: "10"
    sc1.storageclass.storage.k8s.io/persistentvolumeclaims: "20"

3.4 对象数量指标详解

对象数量配额虽然不直接产生计算或存储成本,但会影响集群的调度密度、控制平面负载以及 IP 地址消耗,间接影响整体成本。

指标名称 影响范围 成本关联性
pods Pod 数量上限 直接决定节点密度,影响节点数量和集群规模
services Service 数量上限 影响负载均衡器数量(云环境按个计费)
configmaps ConfigMap 数量上限 影响 etcd 存储压力,间接影响控制平面成本
secrets Secret 数量上限 影响 etcd 存储压力,间接影响控制平面成本
persistentvolumeclaims PVC 数量上限 每个 PVC 对应一个云盘,直接产生存储成本

3.5 指标采集与 Prometheus 集成

在云原生成本分摊模型中,需要将 Resource Quota 指标暴露给 Prometheus 进行采集和告警。Kubernetes 的 kube-state-metrics 组件原生支持 Quota 指标。

以下是一个典型的 Prometheus 采集配置示例:

# prometheus.yml 中的 scrape_config 片段
scrape_configs:
  - job_name: 'kube-state-metrics'
    static_configs:
      - targets: ['kube-state-metrics:8080']
    metric_relabel_configs:
      # 只保留 ResourceQuota 相关指标
      - source_labels: [__name__]
        regex: 'kube_resourcequota.*'
        action: keep

采集到的关键指标包括:

  • kube_resourcequota{resource="requests.cpu", type="hard"} — Quota 硬限制
  • kube_resourcequota{resource="requests.cpu", type="used"} — 当前使用量
  • kube_resourcequota{resource="pods", type="hard"} — Pod 数量上限
  • kube_resourcequota{resource="pods", type="used"} — 当前 Pod 数量
注意:Quota 指标中的 used 值反映的是命名空间内所有 Pod 的 requests 总和,而非实际瞬时使用量。在成本分摊时,需要区分“预留成本”(基于 requests)和“实际使用成本”(基于 Metrics Server 的 container_cpu_usage_seconds_total 等指标)。

3.6 告警分层策略

基于 Resource Quota 指标,可以构建三层告警体系,从成本预警到强制限制逐步升级:

Resource Quota 告警分层模型 L1:成本预警(使用率 > 70%) 触发条件:kube_resourcequota_used / kube_resourcequota_hard > 0.7 动作:发送通知至 FinOps 团队,建议优化资源请求 L2:容量告警(使用率 > 85%) 触发条件:kube_resourcequota_used / kube_resourcequota_hard > 0.85 动作:自动触发 HPA 扩容评估,通知 SRE 团队介入 L3:强制限制(使用率 > 95%) 触发条件:kube_resourcequota_used / kube_resourcequota_hard > 0.95 动作:拒绝新 Pod 调度,触发 P1 级事件响应流程 告警频率:L1 每 6 小时一次,L2 每 30 分钟一次,L3 实时触发

3.7 关键指标总结

在云原生成本分摊模型中,Resource Quota 的每个指标都对应着明确的成本维度。以下表格总结了各指标与成本分摊的映射关系:

指标类别 具体指标 成本分摊维度 采集频率建议
计算资源 requests.cpu / requests.memory 预留成本(按核时/GB时计费) 30 秒
计算资源 limits.cpu / limits.memory 上限成本(防止超卖失控) 30 秒
存储资源 requests.storage 存储容量成本(按 GB/月计费) 5 分钟
存储资源 persistentvolumeclaims 存储实例成本(按 PVC 数量计费) 5 分钟
对象数量 pods 调度密度成本(影响节点数量) 1 分钟
对象数量 services / configmaps / secrets 控制平面成本(影响 etcd 和负载均衡器) 5 分钟
最佳实践:在实施成本分摊时,建议将 requests 指标作为“硬成本”基准,将 limits 和实际使用量作为“弹性成本”调节因子。通过 Prometheus 的 recording rules 预先计算分摊比例,可以显著提升成本报表的查询性能。