多租户 K8s 的 GPU 指标怎么隔离：一个开源代理方案
开源项目 prometheus-multi-tenant-proxy 在现有 Prometheus 前加了一层租户感知代理：用 kube-rbac-proxy 做认证、用 prom-label-proxy 强制注入命名空间过滤，让每个团队只看到自己的 GPU 指标，并通过 MetricAccess 声明要采集的指标；开启采集期隔离后，单租户存储的序列数可从一万多条降到约 300 条。
作者：核流编辑 · 栏目：资源
共享 Kubernetes 集群里的 GPU 指标有两个老问题：租户不该看到别人的数据，所有查询又都压在同一套 Prometheus 上，容易互相拖慢。开源项目 prometheus-multi-tenant-proxy 的思路是在现有 Prometheus 前面加一层薄的租户感知代理，把机制交给平台、把策略交给租户。 它把工作拆成三步：识别调用方属于哪个租户、把查询限制在该租户的命名空间、再把精选指标投递到租户自己的 Prometheus。查询侧由 kube-rbac-proxy 负责 Kubernetes 原生认证，prom-label-proxy 再给每条查询注入命名空间过滤，让 PromQL 无法绕过；代理本身以非 root 身份运行，根文件系统只读。写路径则按租户声明的清单远程写入，高可用副本都会收到相同数据。 如何获取与开始使用 租户只需写一份 YAML：在 MetricAccess 资源里列出指标（支持精确名称、正则和 PromQL 选择器）、是否开启采集期隔离（metricIsolation）以及远程写入目标；查询时带上租户命名空间请求头即可。开启采集期隔离后，单租户存储的序列数可从约一万条降到 300 条左右，查询更快、成本更低。 仓库、清单和示例都已按 Apache 2.0 开源，适合维护共享 GPU 集群的平台团队试用，入口见文末参考资料。官方博客还演示了用一组 PromQL 查询暴露闲置 GPU 的做法：例如统计最近一小时利用率低于 5% 的卡，把“占了不用”的容量找出来。 参考资料 CNCF Blog：Whose GPUs are these, anyway? Secure, self-service metrics for multi-tenant Kubernetes prometheus-multi-tenant-proxy：prometheus-multi-tenant-proxy (Apache-2.0)