Sorun, açık bir operasyonel paradokstan kaynaklanıyor: Adobe ortamında GPU kullanım verileri merkezi bir Prometheus içinde her saniye toplanıyordu, ancak bu birimlerin maliyetini üstlenen ekipler kendi metriklerini doğrudan göremiyordu. Mühendisler Bingi Narasimha Karthik ve Ramkumar Nagaraj'a göre bu durum, 11 gün boyunca sıfır kullanımda kalan bir GPU'nun keşfedilmesine yol açtı; GPU atanmış ve çalışır durumdaydı, ancak kendisinden sorumlu ekip tarafından görülemiyordu.
9 Eylül 2026'da CNCF blogunda yayımlanan makale, yeni bir ticari ürün sunmuyor; bunun yerine çok kiracılı Kubernetes kümelerinde metriklere kendiliğinden ve güvenli erişim oluşturmak için pratik bir modeli açıklıyor. Temel fikir, merkezi Prometheus'un önüne kiracı farkındalığına sahip bir ara katman yerleştirmek, ardından her ekibe verilerinin seçilmiş bir bölümünü vermek ve gerektiğinde bu verileri kendi Prometheus'una kopyalama seçeneği sunmak.
Merkezi Prometheus'a erişim açmak neden yeterli değil?
Yazarlara göre ekiplerin merkezi Prometheus sorgu uç noktasına okuma yetkisiyle erişmesine izin vermek iki sorunla karşılaşıyor. İlki güvenlik sorunu: Prometheus sorgu uç noktası ad alanlarının farkında değil; PromQL sorgusu çalıştırabilen biri teorik olarak istek oranları veya kapasite planları gibi diğer ekiplerin verilerini talep edebilir.
İkinci sorun ise performans. Merkezi depo filonun tamamına ait metrikleri sunuyor ve yüzlerce mühendisten gelen uzun veya hesaplama açısından ağır sorgular kaynak tüketerek herkes için yanıt süresini artırabilir. Bu nedenle ortak depoyu açmak görünürlük sorununu çözmekle kalmaz; mimariye veri sızıntısı riskini ve gürültücü komşu sorununu da ekleyebilir.
Üç sorumluluğa sahip ara katman
Tasarım, Prometheus'un önünde birbiriyle bağlantılı üç işlevi yerine getiren ince bir katman öneriyor:
- Tanımlama: İsteği yapanın kimliğini doğrulamak ve hangi kiracıya ait olduğunu belirlemek.
- Yalıtım: Her sorguyu kiracının ad alanıyla sınırlandırmak ve kısıtlamayı sorgu Prometheus'a ulaşmadan önce uygulamak; böylece PromQL üzerinden bu kısıtlamanın aşılması mümkün olmuyor.
- Teslim: İhtiyaç halinde, kiracının seçilmiş bir metrik kümesini düzenli olarak kendi Prometheus'una kopyalamak.
Okuma yolu, yük dengelemesi için Nginx'i, ardından kimlik doğrulama ve yetkilendirme için kube-rbac-proxy'yi kullanıyor. Daha sonra istekler, Kubernetes API üzerinden Prometheus sunucularını keşfeden ve sonuçları sağlıklı sunuculardan toplayan proxy'ye ulaşıyor. Yazma yolu ise seçilmiş metrikleri kiracının kendi Prometheus'una göndermek için remote write kullanıyor. Yüksek erişilebilirlik ortamlarında veriler, Pod'lara ait DNS adları üzerinden tüm replikalara gönderiliyor.
Yalıtım kimlikle başlayıp veride sona eriyor
kube-rbac-proxy, isteği yapanı belirlemek için Kubernetes kimliği ve RBAC'den yararlanıyor, ardından kiracının kimliğini ad alanı onayı biçiminde iletiyor. prom-label-proxy ise sorgu sırasında yalıtımı uyguluyor; isteği Prometheus'a göndermeden önce ad alanı seçicisi ekleyecek şekilde yeniden yazıyor. Böylece yalıtım, kullanıcının uyması önerilen bir politika olmaktan çıkıp her sorguya uygulanan bir kısıt haline geliyor.
Kaynakta proxy'nin kendisini güçlendirmeye yönelik önlemler de belirtiliyor. Bunlar arasında proxy'yi 65534 UID'li root olmayan bir kullanıcı olarak çalıştırmak, salt okunur kök dosya sistemi kullanmak, tüm ek yetkileri kaldırmak, ayrıcalık yükseltmeyi engellemek ve mümkün olan en düşük yetkilere sahip bir hizmet hesabı vermek bulunuyor.
Maliyet ve performans açısından pratikte ne değişiyor?
Yalıtım, başkalarının verilerini görmeyi engellemekle sınırlı değil. metricIsolation ayarı, metrik toplama aşamasından itibaren ad alanı filtresi uygulanmasını sağlıyor; böylece kiracının kendi Prometheus'u yalnızca kendisine ait serileri depoluyor. Yazarlara göre tipik bir kiracı için depolanan seri sayısı yaklaşık %97 azalabiliyor; 10 binden fazla seriden birkaç yüz seriye düşebiliyor.
Bu azalma daha küçük bir depo, daha hızlı sorgular ve daha düşük depolama maliyeti anlamına geliyor. Ayrıca gereksiz metrikler özel depoya hiç ulaşmadığı için veri sızıntısı olasılığını azaltıyor. Tasarım, günlük panoları ve uyarıları ortak depoya sürekli dayanmak yerine kiracı depolarına taşıyarak merkezi Prometheus üzerindeki yükü de hafifletiyor.
Kendiliğinden işletim için net sınırlar gerekiyor
Ekip, Kubernetes'te MetricAccess adında özel bir kaynak tanımlıyor. Bu kaynak ad alanını, istenen metrikleri, remote write hedefini ve toplama aralığını belirliyor. Kiracılar belirli metrik adlarını, düzenli ifadeleri veya PromQL seçicilerini seçebiliyor. Hedef Prometheus'un web.enable-remote-write-receiver üzerinden remote write alımını etkinleştirmesi gerekiyor; bunun dışındaki altyapı ise olağan Prometheus ve Kubernetes bileşenlerine dayanıyor.
Makale, ad alanı başına ortalama GPU kullanımını, bir saat boyunca kullanımı %5'in altında kalan birimlerin sayısını, kullanılan bellek oranını, güç tüketimini, istek trafiği olmadan çalışır durumdaki birimleri veya GPU birimleri boşta kalırken isteklerin mevcut olmasını tespit etmeyi içeren altı yararlı sorgu türü sunuyor. Örnek, DCGM türündeki metriklere dayanıyor ve adların gerçekten kullanılan dışa aktarıcıyla uyumlu hale getirilmesi gerektiği konusunda uyarıyor.
Deneyim, kendiliğinden işletimin engellerin kaldırılması anlamına gelmediğini gösteriyor. Seçilen metrik kümeleri ve farklı toplama aralıkları yükü sınırlayan kotalar gibi çalışıyor. Ayrıca remote write seçeneği, gerçek panolara ve uyarılara sahip ekiplerle sınırlandırılmalı; küçük ekipler için sorgu sırasında kısıtlı erişim yeterli olabilir.
certi.news'un değerlendirmesi
Buradaki önemli değişiklik, başka bir izleme aracı eklemek değil; yalıtımı altyapının kontrolünde tutarken görünürlük üzerindeki denetimi yalnızca platform ekibinden kiracıya taşımak. Bu, aynı anda bir güvenlik, maliyet ve performans sorununu ele alıyor. Ancak çözüm otomatik değil: metriklerin seçilmesi, cardinality'nin ayarlanması, yeniden denemelerin ele alınması, yüksek erişilebilirlik replikalarına yazılması ve dışa aktarıcı sürümlerinin sabitlenmesi sürekli operasyonel sorumluluklar olmaya devam ediyor.
Yaklaşık %97 seri azalması da dahil olmak üzere verilen sayısal sonuçlar, yazarların deneyine ve «tipik bir kiracıya» ait; her küme için genel bir garanti değil. Bu nedenle model geniş ölçekte benimsenmeden önce her ortamın metrik adları, seri hacmi ve toplama aralıklarıyla test edilmesi gerekiyor. Proje Apache 2.0 kapsamında kullanılabilir durumda ve makalede GitHub'daki prometheus-multi-tenant-proxy deposuna bir bağlantı yer alıyor.