Kubernetes Teams Get a Safer Way to See Their Own GPU Metrics

Kubernetes 团队获得更安全的查看自身 GPU 指标的方法 - InfoQ

InfoQ 首页 News Kubernetes 团队获得更安全的查看自身 GPU 指标

DevOps

从 Token 到功能：为 AI 辅助工程构建成本归因架构（10 月 29 日网络研讨会）

Kubernetes 团队获得更安全的查看自身 GPU 指标

Sep 29, 2026 3 分钟阅读

作者：

• Craig Risi

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 赞

Bluesky

收听本文 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

Adobe 工程师描述了一种开源方法，使团队能够在多租户 Kubernetes 环境中自助访问自己的 Prometheus 指标，而无需暴露其他团队的共享指标。该设计特别针对 GPU 密集型环境，团队可能需要了解利用率和功耗，以判断昂贵的加速器容量是否实际被使用。

这个问题看似简单但难以安全解决。中央 Prometheus 实例可能包含数千个命名空间的指标，因此不适合无限制的租户访问。为每个团队提供查询访问权限可能会暴露其他团队的数据，而允许大量用户查询共享存储库也会产生性能问题和噪声邻居问题。Adobe 的解决方案在用户和中央 Prometheus 之间放置了一个租户感知代理，并可选择为每个租户提供自己的小型 Prometheus 实例。

该架构使用现有的 Kubernetes 和 CNCF 技术，而不是引入另一个指标平台。请求通过 NGINX 和 kube-rbac-proxy 进行身份验证和授权，然后到达多租户 Prometheus 代理。代理识别租户，发现可用的 Prometheus 后端，并将查询限制在该租户的命名空间内。

一个关键组件是 prom-label-proxy，它修改传入的 PromQL 查询以强制实施命名空间限制。这一点很重要，因为仅仅要求开发人员在查询中包含正确的命名空间无法提供足够的安全边界。限制在查询到达 Prometheus 之前由代理应用，防止租户故意构建访问其他命名空间的查询。

该平台还引入了一个名为 MetricAccess 的 Kubernetes 自定义资源，允许团队声明所需的指标。指标定义可以使用精确的指标名称、正则表达式或 PromQL 选择器。这提供了一种自助服务机制，同时将底层收集和访问控制留给平台团队。

对于需要自己仪表板和警报的团队，设计可以定期将精选的指标远程写入租户特定的 Prometheus 实例。启用 metricIsolation 后，仅收集租户自身的指标序列，减少租户 Prometheus 中存储的数据量，同时限制可查询的内容。

Adobe 报告称，一个示例配置将租户存储的指标序列从超过 10,000 个减少到约 300 个。除了减少存储和查询需求外，这还创建了另一个隔离边界：从未收集到租户存储中的数据无法通过该存储后续暴露。

这种分离还改变了运营模式。中央 Prometheus 仍然提供基础设施范围的采集，而特定租户的 Prometheus 实例则处理各个团队所需的仪表板和查询。因此，共享系统无需处理每个开发者的常规可观测性查询。

最直接的应用场景是 GPU 可见性。加速器容量可能代表显著的基础设施成本，但仅分配本身并不能说明这些 GPU 是否在执行有用的工作。作者描述了发现一个 GPU 的情况：尽管已被分配并开启电源，但连续 11 天的利用率始终为零。

通过访问 GPU 利用率、帧缓冲区内存、功耗和请求速率等指标，团队可以构建查询来识别空闲 GPU、在没有对应应用流量情况下消耗电力的 GPU，或在 GPU 容量未充分利用时仍接收流量的工作负载。

尽管 GPU 提供了最明显的示例，但该架构并非特定于 GPU。其底层模式是基于认证、查询隔离、精选指标访问和可选的按租户存储构建的租户感知可观测性层。

随着 Kubernetes 集群逐渐成为应用团队、数据工作负载和 AI 工作负载的共享平台，这一模式变得越来越重要。平台团队需要为开发者提供足够的可观测性，而无需将中央遥测系统转变为安全风险或性能瓶颈。

针对同一底层多租户问题已有几种成熟方案。例如，Grafana Mimir 的架构内置了多租户隔离功能，使用租户标识符来限定指标查询，并要求认证层来建立适当的租户上下文。Mimir 还提供了查询前端功能来管理并扩展读取路径。Cortex 项目是多个 Prometheus 兼容托管服务的基础，它使用类似的 X-Scope-OrgID 模型在租户之间隔离指标数据。而 Adobe 的方法则有所不同，它在保留共享 Prometheus 环境的同时，增加了 Kubernetes 感知的访问控制和基于命名空间的过滤。

关于作者

作者信息

#### Craig Risi

显示更多

显示更少

#### 本文属于 DevOps 主题

##### 相关主题：

• DevOps
• GPU
• Adobe
• Kubernetes
• 指标
• 相关编辑
• 相关赞助商 AI Agent Swarm Patterns（InfoQ 网络研讨会）- 立即观看录像
• 相关赞助商 在全球最广泛采用的基于 Actor 的运行时上构建和运行数据、API 和代理 AI 服务。Akka 服务具有弹性、敏捷和韧性。了解更多。

InfoQ 新闻通讯

每周五发送 InfoQ 最新内容摘要，每 Tuesday 发送一次。加入超过 250,000 名高级开发者的社区。查看示例

我们保护您的隐私。