3. Resource Quota 核心指标:CPU、内存、存储、Pod 数量、PVC 数量等关键配额指标
Resource Quota 是 Kubernetes 中实现多租户资源隔离与成本分摊的核心原语。在云原生 FinOps 实践中,准确理解 Quota 所涵盖的各类指标,是构建成本模型、设置告警阈值以及进行容量规划的基础。本章将逐一拆解这些关键配额指标,并分析其在成本分摊场景下的实际意义。
3.1 核心指标全景图
Kubernetes 的 Resource Quota 支持对计算资源、存储资源和对象数量进行三层维度的限制。以下 SVG 展示了这三大类指标及其在集群中的层级关系:
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 指标,可以构建三层告警体系,从成本预警到强制限制逐步升级:
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 预先计算分摊比例,可以显著提升成本报表的查询性能。