Skip to main content

> kubernetes_çok_kiracılı_maliyet_dağıtımı_&_sahiplik_ataması

Kubernetes Çok Kiracılı Maliyet Dağıtımı & Sahiplik Ataması

Platform ekipleri, paylaşımlı Kubernetes altyapı faturalarını onlarca bağımsız mühendislik ekibine nasıl adil ve hatasız paylaştırır?

ÖZET VE TEKNİK CEVAP

OpenCost veya Kubecost ile pod bazında CPU/RAM talep ve fiili kullanım metriklerini toplayarak, spot/on-demand düğüm fiyatlarını hesaba katarak ve atıl kapasite ile DaemonSet genel giderlerini tenant namespace'lerine matematiksel olarak paylaştırarak.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Çok kiracılı Kubernetes kümelerinde bulut sağlayıcılar konteyner bazında değil, alttaki VM düğüm havuzu bazında fatura keser. Maliyet dağıtım ajanları, Kubernetes API kaynak taleplerini ve Prometheus kullanım metriklerini bulut fatura API'leriyle eşleştirir. Formül: Atanan Maliyet = max(Talep Edilen, Kullanılan) * Birim Fiyat + Orantılı Atıl Kapasite Payı + Amorti Edilmiş Sistem DaemonSet Payı.

2. Doğru Kullanım Senaryosu

Birden fazla bağımsız ürün ekibinin mikroservislerini barındıran merkezi paylaşımlı EKS, GKE veya AKS kümelerini işleten platform mühendisliği ekipleri için zorunludur.

3. Prodüksiyon Arıza Modları

Bir yazılım ekibi pod kısıtlamasını (throttling) engellemek için aşırı kaynak talep eder (0.5 vCPU kullanırken 32 vCPU talep eder). Kubernetes scheduler pahalı yeni düğümler açar ve fatura ikiye katlanırken ekip yalnızca ufak bir miktar kullandığını iddia eder.

4. Teşhis ve Telemetri Sinyalleri

1. Küme toplam kaynak rezervasyon oranı %85'i geçerken fiili CPU/RAM kullanımının %20 altında kalması. 2. Aylık FinOps raporlarında 'sahipsiz harcama' oranının yüksek çıkması. 3. Ekipler arasında ortak küme faturası payı konusunda yaşanan anlaşmazlıklar.

5. Önleme ve Mimari Bariyerler

Pod kaynak taleplerini tarihsel p95 kullanımına göre küçültmek için VPA'yı (Vertical Pod Autoscaler) öneri modunda çalıştırın. Katı Namespace kotaları uygulayın ve ekipleri tasarrufa teşvik etmek için faturalandırmayı fiili tüketime değil talep edilen rezerve kaynağa göre yapın.

6. Mimari Ödünleşimler (Trade-offs)

Küme içi telemetri toplayıcıları işletme ve paylaşımlı gider kuralları üzerinde ekip mutabakatı sağlama yüküne karşılık; çok kiracılı kör noktaları yok eder ve sorumsuz kaynak israfını önler.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO, 150 düğümlü bir EKS kümesinde OpenCost devreye aldı. 'Öneri Ekibi'nin optimize edilmemiş JVM bellek talepleri yüzünden 70.000 dolarlık küme faturasının 42.000 dolarından sorumlu olduğu ortaya çıktı. Pod tanımları küçültülüp dinamik HPA kurulduktan sonra ekibin maliyeti 11.500 dolara geriledi.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Kubernetes maliyet dağıtımı Talep Edilen (Request) mi yoksa Kullanılan (Usage) kaynağa göre mi faturalanmalıdır?

Öncelikle Talep Edilen kaynağa göre faturalanmalıdır; çünkü Kubernetes scheduler düğüm kapasitesini talebe göre kilitler ve başkalarının kullanımını engeller.
Q2

Bir Kubernetes kümesindeki sahipsiz atıl düğüm kapasitesi ekiplere nasıl paylaştırılmalıdır?

Her kiracının kümedeki toplam talep edilen kaynak payına oranlanarak veya merkezi platform genel gider bütçesine yazılarak.
Q3

OpenCost CNCF FinOps standartlarında nasıl bir rol oynar?

Gerçek zamanlı Kubernetes konteyner işlem, ağ ve depolama harcamalarını ölçmek için açık kaynaklı ve bağımsız CNCF standardı olarak hizmet eder.

Kubernetes Çok Kiracılı Maliyet Dağıtımı & Sahiplik Ataması — Sıkça Sorulan Sorular

Datadog agent veya Fluentbit gibi DaemonSet'lerin maliyeti nasıl dağıtılır?

DaemonSet maliyetleri ortak altyapı genel gideri kabul edilir ve o düğümdeki tüm aktif kiracı pod'larına orantılı olarak paylaştırılır.

Çok kiracılı kümelerde Spot düğüm tasarrufları kiracılara nasıl yansıtılır?

OpenCost pod'un çalıştığı spot düğümün anlık indirimli fiyatını hesaplar ve spot uyumlu çalışan ekibe bu indirim avantajını doğrudan yansıtır.

Etiket tabanlı maliyet dağıtımı birden fazla Kubernetes kümesi genelinde çalışabilir mi?

Evet; standart etiketler (`team`, `cost-center`, `environment`) zorunlu tutularak ve metrikler merkezi bir FinOps motorunda toplanarak sağlanır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • Gereğinden fazla tanımlanmış pod CPU/bellek talepleri, Kubernetes ortamlarındaki en büyük bulut israfı kaynağıdır.
  • Ekipler ortak bir test namespace'i paylaştığında yalnızca Namespace bazlı maliyet dağıtımı yetersiz kalır.

Yaygın Yanılgılar

  • Pod talepleri optimize edilmeden HPA (Horizontal Pod Autoscaler) kurmanın altyapı maliyetini otomatik olarak düşüreceğine inanmak.

Karar Kılavuzu & Önceliklendirme

Vakit kaybetmeden OpenCost veya Kubecost kurun, metrikleri Prometheus'a aktarın ve tüm mühendislik liderlerine aylık showback raporu sunun.

Doğrulanmış Kaynaklar & Referanslar