多租户 Kubernetes 的 GPU 指标为什么需要自助与隔离

多租户 Kubernetes 的 GPU 指标不能只解决“有没有采集”，还要同时回答两个问题：租户能不能自己看到并据此行动，以及这个查询是否永远不会越过自己的边界。只有自助没有隔离，等于把共享 Prometheus 的全局视野暴露给租户；只有隔离没有自助，指标仍然躺在平台团队手里，空闲 GPU、异常功耗和低利用率都很难及时归责。

CNCF 在 2026 年 9 月发布的多租户安全自助指标案例正好把这个矛盾说清楚：基础设施 Prometheus 已经持续记录 GPU 利用率，但租户不能直接访问它。案例中甚至发现一块 GPU 连续 11 天处于零利用率状态。问题不是缺少遥测，而是数据没有以安全、可归属、可操作的方式回到资源使用者手里。

基线：集中采集不等于租户可观测

平台侧常见的第一阶段是“先把数据收上来”。例如 NVIDIA DCGM Exporter 可以把 GPU 遥测转换为 Prometheus exposition format，并在 Kubernetes 环境中建立 Pod 映射。这样平台能够集中观察利用率、显存、温度、功耗等序列，但集中存储天然拥有跨命名空间视野。

这时会出现一个看似矛盾的结果：平台知道集群总体消耗，租户却不知道自己名下哪块卡在空转；租户知道业务变慢，却无法把请求量、Pod 状态和 GPU 利用率放进同一条查询里。成本审核最终只能停在“我们大概用了多少”，无法回答“是谁在用、是否用满、该不该释放”。

直接给租户开放共享 Prometheus 也不是合理捷径。Prometheus 查询端点本身不会自动理解“当前调用者只属于某个命名空间”。只要请求能够自由执行 PromQL，就可能读到其他团队的容量、请求率和运行节奏。多租户环境里的指标既是运维数据，也可能泄露业务规模和资源计划。

假设：让指标归属可见，才能让成本动作发生

GPU 观测的目标不是再造一套漂亮看板，而是缩短“发现—归属—行动”的路径。平台需要验证的假设是：当每个租户可以安全查询自己的 GPU 指标，并把它们与自己的流量、队列和工作负载状态关联时，空闲容量才会被释放，异常配置才会被修正，预算责任才会落到实际使用者。

这三个状态可以用一张判断表区分：

改动点：查询隔离必须发生在 PromQL 之前

CNCF 案例采用的核心思路不是给每个租户复制一套完整监控栈，而是在已有基础设施 Prometheus 前增加一层租户感知的查询路径。它包含三个动作：

• 识别：先认证调用者，并确定其租户或命名空间身份。
• 隔离：在请求进入共享 Prometheus 前，强制加入租户标签约束。
• 交付：按需把经过筛选的指标远程写入租户自己的小型 Prometheus。

身份与授权可以由 kube-rbac-proxy 处理，查询标签约束由 prom-label-proxy 负责。关键点不在组件名称，而在约束发生的位置：过滤必须位于查询语言之下，不能只靠使用规范提醒租户“请主动加上 namespace 条件”。

可以把这种约束理解为一次不可绕过的重写。租户提交：

avg(DCGM_FI_DEV_GPU_UTIL)

代理转发给后端的实际语义必须等价于：

avg(DCGM_FI_DEV_GPU_UTIL{namespace="tenant-a"})

无论租户怎样组合聚合函数、子查询或标签选择器，都不能删除平台注入的边界。如果隔离只依赖 Grafana 仪表盘变量、前端下拉框或文档约定，用户绕开界面直接访问查询 API 时，边界就不存在了。

自助契约：租户选择指标，平台控制机制

如果所有指标都由平台团队手工配置，自助最终会退化成工单队列。CNCF 案例引入 MetricAccess 自定义资源，让团队声明自己需要哪些指标。租户拥有“要看什么”的选择权，平台保留“如何认证、如何过滤、允许哪些范围、多久采一次”的机制控制权。

一个实用的自助契约至少要描述四类信息：

• 租户身份与对应的命名空间或标签范围；
• 允许访问的指标名称或经过审核的指标集合；
• 查询或采集周期，避免所有租户都使用高频率；
• 交付方式，是通过代理查询，还是远程写入租户指标库。

GPU 指标不应脱离业务指标单独阅读。利用率低可能意味着确实没有流量，也可能是调度错位、批任务等待数据、模型加载失败或资源申请过大。租户真正需要的是把 DCGM_FI_DEV_GPU_UTIL 与请求率、队列深度、Pod 状态、作业阶段组合起来。例如，持续有请求但 GPU 利用率接近空闲，更像调度或应用路径问题；没有请求且 GPU 长期占用，则更像容量释放问题。

压测与验收：不要只看“能查询成功”

这类系统的验收重点不是某条 PromQL 返回了数据，而是边界、归属和负载都能经受异常输入。建议把验证分成四组。

1. 越权验证

分别用租户 A 和租户 B 的身份提交普通查询、带其他命名空间标签的查询、正则匹配查询和子查询。结果必须始终被限制在调用者自己的范围。任何“查询成功但返回空”之外的跨租户序列都应视为隔离失败。

2. 归属验证

确认 GPU 遥测与命名空间、Pod、工作负载之间的标签链完整。如果 exporter 没有输出预期映射，或者集群间的指标名不一致，代理再安全也只能返回“没有数据”。NVIDIA 的DCGM Exporter 文档说明了 Kubernetes Pod 映射能力；生产中仍应固定 exporter 版本，并记录实际暴露的序列名。

3. 查询负载验证

限制可选指标集、查询并发和采集周期。CNCF 案例强调，经过筛选的指标集合可以减少代理处理的序列基数，而不同租户可以使用不同采集间隔。实时推理团队可能需要较短周期，离线批处理团队可能只需几分钟一次，不应让后者承担前者的存储和查询成本。

4. 故障验证

模拟后端 Prometheus 不可用、租户指标库重启、远程写入超时和高可用副本切换。租户查询路径要有明确错误，远程写入要有重试与退避，且不能因为某个租户的失败拖慢全部租户。若租户使用多个 HA 副本，还要明确写入一致性策略。

结果判断：什么情况下值得增加租户指标库

不是每个租户都需要自己的 Prometheus。小团队只需要偶尔检查利用率时，经过过滤的代理查询已经足够；为每个命名空间建立独立存储反而增加运维成本。只有当团队需要自主管理长期看板、告警规则、保留周期，或者需要与内部业务指标稳定关联时，才值得启用 per-tenant remote-write。

因此，结果不能只用“上线了多少租户指标库”衡量。更合适的判断标准包括：

• 租户能否在不提交平台工单的情况下定位自己的空闲 GPU；
• 跨租户查询是否在代理层被强制阻断；
• 指标的命名空间、Pod 和 GPU 归属是否完整；
• 单个租户的高频查询是否会影响其他租户；
• 发现问题后是否能触发释放容量、调整请求或修复调度等动作。

边界条件：指标隔离不等于 GPU 运行时隔离

本文讨论的是“谁能看到哪些指标”，不是“谁能使用哪块 GPU”。命名空间标签过滤可以阻止租户读取其他团队的时间序列，却不能提供显存隔离、故障域隔离、调度配额或网络隔离。GPU 的运行时共享仍要根据硬件与信任边界选择整卡分配、MIG、MPS、time-slicing 或专用节点，并配合 RBAC、NetworkPolicy、ResourceQuota 和调度策略。

也不能把标签当作可信身份本身。标签来自采集链路，身份来自认证与授权，两者必须在代理层绑定。如果租户可以任意伪造用于隔离的标签，或者 exporter 的标签映射不稳定，查询重写看起来正确，数据归属仍可能错误。

最后，自助不是“允许所有指标”。指标基数本身就是成本，过宽的 allowlist 会把共享监控的压力复制到每个租户。好的默认集合、可审计的例外和按租户分级的采集周期，才是自助能够长期运行的前提。

常见问题

多租户 GPU 指标一定要每个租户部署一套 Prometheus 吗？

不一定。安全代理查询适合轻量需求；只有需要独立告警、看板、保留策略或长期关联分析的租户，才需要可选的远程写入与独立指标库。

在 Grafana 里固定 namespace 变量能实现隔离吗？

不能作为安全边界。界面变量可以被绕开，真正的隔离应在请求到达 Prometheus 前强制注入标签约束，并与经过认证的租户身份绑定。

为什么有 GPU 指标却查不到租户数据？

优先检查 exporter 是否输出了目标序列、Pod 与命名空间标签是否完成映射、不同集群的指标名是否一致，以及代理发现的后端是否健康。很多“无数据”并不是权限问题，而是采集与归属链路断开。

自助查询最需要限制什么？

至少限制可访问指标集、查询并发、时间范围和采集周期。高基数指标与高频查询应按租户单独配额，避免一个团队把共享监控拖入新的 noisy neighbor 问题。