Adobe 工程师介绍了一种开源方案，让团队能够在多租户 Kubernetes 环境中自助访问自己的 Prometheus 指标，同时不会暴露其他团队共享的指标数据。该设计尤其针对大量使用 GPU 的环境，因为团队可能需要查看 GPU 利用率和功耗，以了解昂贵的加速器资源是否得到了实际利用。
这个问题很直观，却很难安全地解决。一个中心化 Prometheus 实例可能包含来自数千个命名空间的指标，因此不适合向租户开放不受限制的访问权限。允许每个团队执行查询可能会暴露其他团队的数据，而让大量用户查询共享存储，也可能导致性能问题和“吵闹邻居”问题。Adobe 的解决方案是在用户与中心 Prometheus 之间放置一个能够识别租户的代理，并可选择为每个租户提供一个规模较小的独立 Prometheus 实例。
该架构采用现有的 Kubernetes 和 CNCF 技术，而不是引入另一个指标平台。请求首先经过 NGINX 和 kube-rbac-proxy 完成身份验证和授权，然后再到达多租户 Prometheus 代理。代理会识别租户、发现可用的 Prometheus 后端，并将查询范围限制在该租户的命名空间内。
其中一个关键组件是 prom-label-proxy，它会修改传入的 PromQL 查询，强制添加命名空间约束。这一点非常重要，因为仅仅要求开发者在查询中包含正确的命名空间，并不能形成足够可靠的安全边界。代理会在查询到达 Prometheus 之前应用这一限制，从而防止租户故意构造能够访问其他命名空间的查询。
该平台还引入了一个名为 MetricAccess 的 Kubernetes 自定义资源，允许团队声明自己需要哪些指标。指标定义可以使用准确的指标名称、正则表达式或 PromQL 选择器。这既提供了一种自助机制，又将底层的数据采集和访问控制保留在平台团队手中。
对于需要自有仪表板和告警的团队，该设计可以定期通过 remote write 将经过筛选的一组指标写入租户专属的 Prometheus 实例。启用 metricIsolation 后，只会采集该租户自己的时间序列，既减少租户 Prometheus 中存储的数据量，也限制了可供查询的数据范围。
Adobe 表示，在一个示例配置中，某个租户存储的时间序列数量从超过 10,000 条减少到了约 300 条。除了降低存储和查询需求外，这还形成了另一道隔离边界：从未被采集到租户存储中的数据，之后也就不可能通过该存储暴露出去。
这种分离方式也改变了运维模式。中心 Prometheus 继续负责整个基础设施范围内的数据采集，而租户专属的 Prometheus 实例则负责各个团队所需的仪表板和查询。因此，共享系统不必再为每位开发者的日常可观测性查询提供服务。
眼下最直接的使用场景是 GPU 可见性。加速器资源可能是一项巨大的基础设施成本，但分配了 GPU，并不意味着这些 GPU 正在执行有价值的工作。作者提到，他们曾发现一块 GPU 尽管已经分配并处于通电状态，利用率却连续 11 天保持为零。
借助 GPU 利用率、帧缓冲区内存、功耗和请求速率等指标，团队可以构建查询，识别闲置 GPU、消耗电力却没有对应应用流量的 GPU，或者虽然工作负载正在接收流量、GPU 资源却仍未得到充分利用的情况。
尽管 GPU 是最直观的示例，但该架构并非 GPU 专用。其底层模式是一套面向租户的可观测性层，围绕身份验证、查询隔离、受控的指标访问以及可选的租户专属存储构建。
随着 Kubernetes 集群逐渐成为应用团队、数据工作负载和 AI 工作负载共享的平台，这一点变得越来越重要。平台团队既需要为开发者提供足够的可观测性，又不能让中心遥测系统变成安全风险或性能瓶颈。
针对同一类多租户问题，目前已有多种成熟方案。例如，Grafana Mimir 在架构中内置了多租户隔离能力，使用租户标识符限定指标查询范围，并要求通过身份验证层建立正确的租户上下文。Mimir 还提供查询前端能力，用于管理和扩展读取路径。Cortex 是多个 Prometheus 兼容托管服务所基于的项目，它采用类似的 X-Scope-OrgID 模型，在租户之间隔离指标数据。Adobe 的方案略有不同：它保留共享 Prometheus 环境，同时在外围增加 Kubernetes 感知的访问控制和基于命名空间的过滤机制。
原文链接：https://www.infoq.com/news/2026/09/kubernetes-gpu-metrics/
