Adobe 利用多租户 Prometheus 代理架构解决 Kubernetes GPU 资源监控隔离难题

一句话结论

Adobe 工程师推出基于 Kubernetes 的多租户 Prometheus 代理方案，通过强制命名空间隔离和自定义资源管理，在确保数据安全的前提下实现了 GPU 利用率的高效自助监控。

关键要点

• 该架构在用户与中心 Prometheus 之间部署租户感知代理，利用 `prom-label-proxy` 强制在 PromQL 查询中添加命名空间约束，从底层阻断跨租户数据访问。
• 引入 `MetricAccess` Kubernetes 自定义资源，允许团队通过精确名称、正则表达式或 PromQL 选择器自助声明指标，将访问控制逻辑下沉至平台团队管理。
• 启用 `metricIsolation` 功能时，租户专属 Prometheus 实例仅采集本租户时间序列，示例配置中存储序列数从超过 10,000 条降至约 300 条。
• 请求链路经过 `NGINX` 和 `kube-rbac-proxy` 完成身份验证与授权，随后由代理识别租户并发现后端，将查询范围严格限制在指定命名空间内。
• 该方案并非 GPU 专用，而是一套通用的多租户可观测性层，支持通过 `remote write` 定期将筛选后的指标同步至租户专属存储。

背景与事实

随着 Kubernetes 集群成为应用团队、数据工作负载和 AI 工作负载共享的平台，多租户环境下的可观测性管理面临巨大挑战。Adobe 工程师指出，一个中心化的 Prometheus 实例可能承载来自数千个命名空间的指标，若直接向所有租户开放不受限制的访问权限，将导致严重的数据泄露风险。此外，大量用户直接查询共享存储还会引发性能瓶颈和“吵闹邻居”效应。为此，Adobe 开发了一种开源解决方案，旨在让团队能够自助访问属于自己的指标数据，同时确保其他团队共享的敏感信息不被暴露。

该架构的核心在于现有的 Kubernetes 和 CNCF 技术栈，未引入额外的指标平台。数据流动路径设计严谨：请求首先通过 `NGINX` 和 `kube-rbac-proxy` 完成严格的身份验证和授权，随后到达多租户 Prometheus 代理。代理负责识别当前租户身份，发现可用的 Prometheus 后端，并将查询范围限制在该租户的命名空间内。其中，关键组件 `prom-label-proxy` 扮演了安全守门员的角色。它修改传入的 PromQL 查询，强制添加命名空间约束。这种设计至关重要，因为仅依赖开发者在查询中手动包含正确的命名空间无法形成可靠的安全边界。代理在查询到达 Prometheus 之前应用限制，从根本上防止租户故意构造能够越权访问其他命名空间查询的行为。

除了查询端的隔离，该平台还引入了名为 `MetricAccess` 的 Kubernetes 自定义资源。这一机制允许团队声明自己需要哪些指标，支持使用准确的指标名称、正则表达式或 PromQL 选择器进行定义。这种方式既提供了灵活的自助服务机制，又将底层数据采集和访问控制的复杂性保留在平台团队手中。对于需要自有仪表板和告警系统的团队，设计支持定期通过 `remote write` 将经过筛选的一组指标写入租户专属的 Prometheus 实例。当启用 `metricIsolation` 选项后，系统只会采集该租户自己的时间序列。据 Adobe 介绍，在一个示例配置中，这一机制使某个租户存储的时间序列数量从超过 10,000 条显著减少到约 300 条。

这种分离架构改变了传统的运维模式。中心 Prometheus 继续负责整个基础设施范围内的数据采集，而租户专属的 Prometheus 实例则专注于满足各团队日常的仪表板和查询需求。由此，共享系统不再需要为每位开发者的日常可观测性查询提供服务，从而降低了共享系统的负载压力。Adobe 特别强调，该设计尤其针对大量使用 GPU 的环境，因为团队需要查看 GPU 利用率和功耗等指标，以确认昂贵的加速器资源是否得到了实际利用。

影响分析

对于中文开发者与从业者而言，Adobe 的这套方案为多租户 Kubernetes 环境下的资源监控提供了极具参考价值的落地路径。首先，它展示了一种低侵入性的隔离策略，即不重构底层存储，而是通过代理层和查询重写实现安全边界。这对那些已部署大型中心化 Prometheus 集群、但苦于无法安全开放权限给多个业务部门的企业具有直接的借鉴意义。其次，`MetricAccess` 自定义资源的引入，将指标访问控制标准化为一种声明式 API，降低了团队自助获取特定监控数据的门槛，同时也减轻了平台团队手动管理用户权限的工作量。

在 AI 与大数据工作负载日益占据集群核心资源的背景下，这种架构能有效解决“资源闲置浪费”的痛点。通过精确的时间序列过滤和租户隔离，团队可以构建针对性的查询，识别闲置 GPU、高功耗低负载节点或资源未充分利用的服务。这不仅直接降低了算力成本的盲目投入，还通过减少无效数据写入，优化了存储和查询性能。明确这是一种基于实践的工程判断：在多租户场景中，将“查询隔离”前置到代理层，比在存储层做多租户路由更安全且灵活，尤其适用于需要兼容现有 Prometheus 生态而不愿更换 Mimir 或 Cortex 的存量体系。

适用边界

该方案的结论与优势主要建立在 Kubernetes 环境之上，且假设团队已经具备运行 `NGINX`、`kube-rbac-proxy` 及自定义 Kubernetes 资源的成熟基础设施能力。对于非 Kubernetes 环境、单租户架构或资源规模极小（无需处理成千上万命名空间）的场景，部署如此复杂的代理链路和隔离机制可能带来不必要的运维复杂度。此外，虽然该方案通过 `remote write` 实现了数据隔离，但它依赖定期的同步机制，若租户实时性要求极高，需自行评估租户专属 Prometheus 实例的数据延迟是否可接受。该架构并非 GPU 专用，但在其他低算力场景下，其对于解决“昂贵资源利用率可视性”的核心价值不如 GPU 场景显著。

孤本观察

这是基于 Adobe 公开实践的工程判断：在多租户可观测性设计中，将安全边界下沉至查询重写层（如 `prom-label-proxy`）优于依赖上游用户自觉，这种“默认拒绝、显式授权”的模式是平衡安全性与自助便利性最稳健的架构选择。

来源：InfoQ 中文 AI