这些GPU到底是谁的？多租户Kubernetes的安全自助服务指标
内容提要
Adobe团队通过构建基于CNCF开源组件的多租户代理，解决了GPU利用率不可见的问题。该方案利用kube-rbac-proxy进行认证，prom-label-proxy强制命名空间隔离，并通过MetricAccess自定义资源实现自助服务。按租户收集指标并远程写入独立Prometheus，将存储序列减少97%，使团队能实时监控GPU使用并发现闲置资源。
延伸解读
为什么不能直接开放共享Prometheus
直接给所有租户开放中央Prometheus的读权限看似简单，但会带来两个问题：一是安全风险，PromQL查询不感知命名空间，租户可以查询任意数据；二是性能问题，大量并发查询会导致“吵闹邻居”效应，影响整个集群的稳定性。因此，需要一个中间层来隔离和管控访问。
隔离与成本的双重收益
通过prom-label-proxy在查询时强制注入命名空间标签，并在采集时启用metricIsolation，租户只存储自己的序列，存储量可减少约97%。这不仅提升了查询速度，还降低了存储成本，同时避免了数据泄露风险。对于多租户集群，这种隔离机制是保障安全和控制成本的关键。
自助服务的关键：MetricAccess自定义资源
平台团队无法为每个租户手动配置指标，因此通过MetricAccess自定义资源，租户可以自行声明需要的指标和交付方式。这种设计将平台机制与租户策略分离，既保证了灵活性，又减轻了平台负担。租户只需应用一个YAML文件，即可获得自己的指标视图。
运维中的注意事项
文章提醒，自助服务仍需护栏：指标集需要精心策划，避免过度授权；metricIsolation应默认开启；远程写入的可靠性（重试、备份）必须重视；对于小团队，仅查询过滤可能就足够；此外，跨集群的命名漂移可能导致“无数据”问题，需固定exporter版本并记录指标名称。
Q&A
Adobe团队如何解决多租户Kubernetes中GPU利用率不可见的问题？
Adobe团队构建了一个基于CNCF开源组件的多租户代理，通过kube-rbac-proxy进行认证，prom-label-proxy强制命名空间隔离，并通过MetricAccess自定义资源实现自助服务。该方案按租户收集指标并远程写入独立的Prometheus，使团队能实时监控GPU使用并发现闲置资源。
为什么不能直接共享中央Prometheus给所有租户？
直接共享中央Prometheus存在两个问题：一是安全问题，Prometheus查询端点不感知命名空间，租户可以查询其他租户的数据；二是扩展性问题，大量租户的查询会导致性能下降，产生“吵闹邻居”效应。
多租户代理是如何实现租户隔离的？
多租户代理通过两个组件实现隔离：kube-rbac-proxy负责认证和授权，确认用户身份和权限；prom-label-proxy在查询时强制注入命名空间匹配器，确保任何查询只能访问该租户的命名空间数据，且这种强制发生在查询语言层面之下，无法被绕过。
MetricAccess自定义资源的作用是什么？
MetricAccess是一个Kubernetes自定义资源，允许租户声明他们需要哪些指标以及如何交付。它实现了自助服务，租户通过一个YAML文件即可配置指标收集和远程写入，而平台团队只需维护机制，租户自己管理策略。
metricIsolation设置如何帮助减少存储和成本？
metricIsolation设置为true时，指标收集阶段就通过prom-label-proxy应用命名空间过滤，只收集该租户自己的序列，从而将存储序列从约10,000个减少到约300个，减少了97%的存储量，同时提高了查询速度并降低了成本。
有哪些PromQL查询可以帮助发现闲置的GPU？
文章提供了6个查询，例如：1. 按命名空间平均GPU利用率；2. 统计过去一小时利用率低于5%的GPU数量；3. 计算GPU内存使用比例；4. 按命名空间汇总功耗；5. 检测GPU繁忙但无流量的情况；6. 检测有流量但GPU空闲的情况。其中查询2能有效发现闲置GPU。
多租户代理在扩展性方面有哪些设计？
扩展性设计包括：动态后端发现、独立的每租户远程写入、写入所有HA副本以确保故障转移。此外，通过策展指标集和每租户收集间隔来控制负载，避免下游出现吵闹邻居问题。
实施该方案时有哪些经验教训？
经验教训包括：自助服务需要护栏，策展指标比大允许列表更好；metricIsolation应默认开启；远程写入的失败模式需要预算；对于小团队，仅过滤查询访问可能就足够；跨集群命名可能漂移，应固定导出器版本并记录确切的序列名称。
