問題の出発点は、明白な運用上の矛盾だった。Adobeの環境では、GPUの使用データが中央のPrometheusに毎秒収集されていたが、GPUのコストを負担しているチームは、自分たちのメトリクスを直接確認できなかった。エンジニアのBingi Narasimha Karthik氏とRamkumar Nagaraj氏によると、その結果、割り当てられて稼働しているにもかかわらず、担当チームからは見えないまま、GPUが11日間使用率ゼロになっていたことが判明した。
2026年9月9日にCNCFのブログで公開された記事は、新しい商用製品を紹介するものではない。マルチテナントKubernetesクラスターで、メトリクスへのセルフサービスかつ安全なアクセスを構築するための実践的なパターンを説明している。基本的な考え方は、中央のPrometheusの前にテナントを認識する中間層を配置し、各チームに自身のデータから選別したスライスを提供し、必要に応じてそのデータを専用のPrometheusへコピーできるようにすることだ。
中央のPrometheusを公開するだけでは不十分な理由
著者らによると、チームに中央Prometheusのクエリーエンドポイントへの読み取り権限を与えると、2つの問題に直面する。1つ目はセキュリティだ。Prometheusのクエリーエンドポイントは名前空間を認識しないため、PromQLクエリーを実行できるユーザーは、理論上、リクエストレートやキャパシティープランなど、他チームのデータを要求できる。
2つ目はパフォーマンスだ。中央ストアはフリート全体のメトリクスを提供しており、数百人のエンジニアが実行する長時間または非効率なクエリーによって、リソースが消費され、全員の応答時間が悪化する可能性がある。そのため、共有ストアを公開しても可視性の問題は解決せず、データ漏えいのリスクと「うるさい隣人」の問題を同じアーキテクチャに持ち込むことになりかねない。
3つの責務を担う中間層
この設計では、Prometheusの前に薄い層を置き、相互に関連する3つの機能を担わせる。
- 識別：リクエスト元を認証し、そのユーザーが属するテナントを特定する。
- 分離：各クエリーをテナントの名前空間に制限する。Prometheusにクエリーが到達する前に制約を適用するため、PromQLを使って回避することはできない。
- 配信：必要に応じて、テナントのメトリクスから選別した集合を定期的に専用Prometheusへコピーする。
読み取り経路では、Nginxが負荷分散を行い、続いてkube-rbac-proxyが認証と認可を担当する。その後、リクエストはKubernetes APIを通じてPrometheusサーバーを検出し、正常なサーバーから結果を集約するプロキシに到達する。書き込み経路ではremote writeを使って選別したメトリクスをテナント専用Prometheusへ送信する。高可用性環境では、Pod固有のDNS名を通じて、すべてのレプリカへデータを送信する。
分離はアイデンティティから始まり、データで完了する
kube-rbac-proxyはKubernetesのアイデンティティとRBACを利用してリクエスト元を特定し、テナントのアイデンティティを名前空間の主張として引き渡す。prom-label-proxyはクエリー時に分離を適用する。リクエストを書き換え、Prometheusへ送る前に名前空間セレクターを追加するためだ。これにより、分離はユーザーに推奨されるだけのポリシーではなく、すべてのクエリーに適用される制約になる。
また、記事はプロキシ自体を強化する対策にも言及している。具体的には、UID 65534の非rootユーザーとして実行すること、ルートファイルシステムを読み取り専用にすること、追加の権限をすべて削除すること、権限昇格を防止すること、そして可能な限り最小限の権限を持つサービスアカウントを付与することだ。
コストとパフォーマンスは実際にどう変わるのか
分離の目的は、他者のデータを見えなくすることだけではない。metricIsolation設定により、メトリクス収集の段階から名前空間フィルターを適用できるため、テナント専用Prometheusには自身に関係する系列だけが保存される。著者らの実験によれば、典型的なテナントでは保存される系列数を約97%削減でき、1万系列超から数百系列まで減少する可能性がある。
この削減により、より小規模なストア、より高速なクエリー、より低いストレージコストを実現できる。また、不要なメトリクスがそもそも専用ストアに到達しないため、データ漏えいの可能性も低下する。この設計は中央Prometheusへの負荷も軽減する。日常的なダッシュボードやアラートが、共有ストアに継続的に依存するのではなく、テナントのストアへ移行されるからだ。
セルフサービス運用には明確な境界が必要
チームはKubernetesのカスタムリソースであるMetricAccessを定義し、名前空間、必要なメトリクス、remote writeの宛先、収集間隔を指定する。テナントは、特定のメトリクス名、正規表現、PromQLセレクターを選択できる。対象となるPrometheusでは、web.enable-remote-write-receiverによるremote writeの受信を有効にする必要がある。一方、それ以外の構成は、通常のPrometheusおよびKubernetesコンポーネントを基盤としている。
記事では、名前空間ごとのGPU平均使用率、1時間にわたって使用率が5%未満のGPU数、使用中メモリの割合、電力消費、リクエストの動きがないまま稼働しているGPU、またはリクエストが存在するにもかかわらずGPUがアイドル状態にあるケースなど、6種類の有用なクエリーを示している。例ではDCGM系のメトリクスを使用しているが、実際に使用するエクスポーターに合わせて名前を調整する必要があると注意している。
この実験は、セルフサービス運用が障壁をなくすことを意味しないことも示している。メトリクスの選別と異なる収集間隔はクォータとして機能し、負荷を制限する。また、remote writeは実際にダッシュボードやアラートを所有するチームに限定すべきで、小規模なチームにはクエリー時の制限付きアクセスだけで十分な場合がある。
certi.newsの見解
ここで重要な変化は、別の監視ツールを追加することではない。インフラストラクチャによる分離の管理を維持しながら、可視性の制御をプラットフォームチームだけからテナントへ移すことだ。これにより、セキュリティ、コスト、パフォーマンスという3つの問題を同時に解決できる。ただし、解決策が自動的に機能するわけではない。メトリクスの選択、カーディナリティの調整、再試行への対応、高可用性レプリカへの書き込み、エクスポーターのバージョン固定は、いずれも継続的な運用上の責任となる。
また、約97%の系列削減を含む記載された数値結果は、著者らの実験と「典型的なテナント」に関するものであり、すべてのクラスターに対する一般的な保証ではない。そのため、このパターンを大規模に採用する前に、各環境固有のメトリクス名、系列数、収集間隔でテストする必要がある。プロジェクトはApache 2.0の下で公開されており、記事にはGitHub上のprometheus-multi-tenant-proxyリポジトリへのリンクが含まれている。