Bulutta Kubernetes kullanmak çoğu ekip için teknik bir başarı gibi görünür; fakat birkaç ay sonra fatura kalemleri incelendiğinde asıl sınav başlar. Ölçeklenebilirlik sağlanmıştır ama maliyet davranışı öngörülemez hâle gelmiştir. Sağlıklı platform mimarisi, performans ile bütçe disiplini arasında bilinçli bir denge kurar.
Maliyet neden sadece bulut ekibinin problemi değildir?
Kubernetes maliyetleri tek bir satırdan oluşmaz:
- Node maliyetleri
- Kalıcı disk ve snapshot giderleri
- Load balancer ve ağ geçidi ücretleri
- Gözlemlenebilirlik veri hacmi
- Boşta duran test ve geçici ortamlar
Platform ekibi bu kalemleri yönetir; ancak asıl tüketimi uygulama davranışı belirler. Bu yüzden FinOps yaklaşımı platform tasarımına gömülmelidir.
Dört katmanlı maliyet kontrol modeli
1. Hesaplama katmanı
Node havuzlarını iş yükü tipine göre ayırın. Her iş yükünü aynı instance ailesine koymak pratik görünür ama pahalıdır. Tipik ayrım şu şekilde olabilir:
- Genel amaçlı uygulamalar
- Yoğun CPU kullanan batch işleri
- Bellek ağırlıklı entegrasyon servisleri
- Spot veya preemptible node üzerinde çalışabilecek toleranslı işler
2. Planlama katmanı
Kaynak istekleri (requests) ve limitler (limits) maliyet üzerinde doğrudan etkilidir. Gerçek kullanım ölçülmeden yazılan konservatif değerler, kümede görünmez kapasite israfı yaratır.
3. Otomasyon katmanı
Cluster autoscaler, node auto-provisioning veya Karpenter gibi çözümler maliyet azaltır; ancak yalnızca doğru etiketleme ve iş yükü sınıflaması varsa çalışır.
4. Yaşam döngüsü katmanı
Preview environment, kısa ömürlü test kümeleri ve haftalarca açık kalan PoC ortamları çoğu zaman ana maliyet kaçağıdır. Otomatik kapanış politikaları olmazsa bütçe disiplini kurulamaz.
Gözlemlenebilirlik olmadan optimizasyon yapılamaz
Bir kümede hangi namespace’in, hangi takımın, hangi servisin ne kadar maliyet ürettiği görünmüyorsa yönetim tahmine dayanır. Bu nedenle:
- Namespace bazlı sahiplik etiketleri zorunlu olmalı
- CPU ve bellek kullanım trendleri tutulmalı
- Boşta çalışan workload’lar raporlanmalı
- Egress ve load balancer maliyetleri ayrı izlenmeli
Kubernetes’te maliyet görünürlüğü yalnızca finansal rapor için değil, mimari kararların geri bildirimi için de gereklidir.
Kurumsal iş yükleri için önerilen yaklaşım
ERP entegrasyonları, arka plan kuyrukları ve API ağ geçitleri aynı kümede çalışabilir; fakat aynı kaynak politikasına sahip olmamalıdır. Örneğin:
- ERP senkronizasyon işleri zaman pencereli ve önceliklidir.
- Web API’ler sürekli yanıt süresi hedefi taşır.
- Raporlama işleri yoğun kaynak tüketebilir ama ertelenebilir.
Bu ayrımı priorityClass, taint/toleration ve ayrı node havuzları ile ifade etmek, hem güvenilirlik hem maliyet açısından daha doğru sonuç verir.
Uygulanabilir optimizasyon listesi
- Her namespace için sahiplik, ortam ve maliyet merkezi etiketlerini zorunlu kılın.
- Son 30 günlük gerçek kullanıma göre request/limit değerlerini gözden geçirin.
- Spot kapasiteye taşınabilecek işler için ayrı havuz açın.
- Çalışma saatleri dışında kapanabilecek ortamları planlı olarak durdurun.
- Gözlemlenebilirlik veri hacmini saklama politikasına göre sınırlayın.
Sonuç
Kubernetes platformu pahalı olduğu için değil, kontrolsüz büyüdüğü için bütçeyi zorlar. Başlangıçta doğru node stratejisi, iş yükü sınıflaması ve yaşam döngüsü otomasyonu kurulduğunda hem geliştirici hızını hem de maliyet öngörülebilirliğini korumak mümkündür. Sağlam platform mühendisliği, kapasiteyi yalnızca artırmak değil; ne zaman, neden ve kimin için artırdığını görünür kılmaktır.