Kubernetes Maliyet Optimizasyonu 2026: Right-Sizing ve Bin Packing Teknikleri

Kubernetes Maliyetini Düşürmenin En Hızlı Yolu Nedir?

Kubernetes maliyetini düşürmenin en hızlı yolu right-sizing’dir: pod request/limit değerlerini gerçek kullanıma göre düzeltmek ve aşırı rezervasyonu (over-provisioning) ortadan kaldırmaktır. CNCF’in FinOps ve maliyet çalışmaları, kümelerin önemli bir bölümünde CPU kullanımının ayrılan kaynağın çok altında kaldığını, ortalama CPU kullanım oranının sıklıkla %15-35 bandında seyrettiğini gösterir. Yani şirketler, hiç kullanmadıkları kapasite için her ay ödeme yapar.

İkinci en büyük kazanç bin packing’dir: pod’ları daha az node’a verimli yerleştirmek ve idle node’ları kapatmak. Right-sizing ile bin packing birlikte uygulandığında, tipik bir üretim kümesinde compute faturasının %40-70’i geri kazanılabilir. Bu rehber, VPA/KRR ile doğru boyutlandırmadan spot instance ve Karpenter ile otomatik konsolidasyona kadar somut tekniklerin tümünü sayısal olarak açar.

Kubernetes maliyetinin neden bu kadar şiştiğini anlamak için iki katmanı ayırmak gerekir: ayrılan kaynak (allocation) ile gerçekten kullanılan kaynak (utilization) arasındaki uçurum. Bir node bulut sağlayıcıdan kiralandığında, üzerinde pod çalışsın ya da çalışmasın tam fiyatı ödenir; fatura, pod’ların gerçek tüketimine değil node’ların açık kalma süresine bağlıdır. Geliştiriciler güvenli tarafta kalmak için pod’lara gerçek ihtiyacın çok üstünde CPU ve bellek isteği (request) tanımladığında, scheduler bu rezervasyonu node’da kilitler ve o kapasite başka pod tarafından kullanılamaz; ortaya çıkan sonuç, ayrılmış ama hiç dokunulmamış kapasite için sürekli ödeme yapmaktır. Sektör ölçümleri, birçok kurumsal kümede ortalama CPU kullanımının %15-35, bellek kullanımının ise %30-50 bandında kaldığını gösterir; yani ödenen kapasitenin yarısından fazlası atıl durur. Maliyet optimizasyonunun tüm mantığı, bu allocation-utilization uçurumunu kapatmaya dayanır.

Maliyet İsrafının Kaynakları

Kubernetes faturası şişerken, israfın neredeyse tamamı birkaç tekrarlayan nedene dayanır. İsrafı görmek için önce kaynağını isimlendirmek gerekir.

• Aşırı request: Geliştirici “garanti olsun” diye CPU/bellek isteğini gerçek ihtiyacın 3-5 katı verir; scheduler bu rezervasyonu node’da bloke eder.
• Idle node: Düşük yoğunlukta yerleştirme nedeniyle yarı boş node’lar 7/24 açık kalır.
• On-demand bağımlılığı: Kesintiye dayanıklı iş yükleri bile pahalı on-demand fiyatla çalışır, spot fırsatı kaçar.
• Orphan kaynaklar: Bağlı olmayan PersistentVolume, eski LoadBalancer ve kullanılmayan IP’ler sessizce fatura üretir.
• Boyutsuz dev/test: Üretim dışı ortamlar gece ve hafta sonu açık bırakılır.

Right-Sizing: VPA, Goldilocks ve KRR ile Doğru Boyut

Right-sizing, pod kaynak isteklerini gerçek tüketime hizalamaktır. Manuel tahmin yerine veriye dayalı araçlar kullanılır. Vertical Pod Autoscaler (VPA) önerilen request değerlerini hesaplar; Goldilocks bu önerileri görsel bir panoda sunar; KRR (Kubernetes Resource Recommender) Prometheus geçmiş verisiyle aşırı/yetersiz rezervasyonu raporlar.

1. Ölç: Prometheus ile en az 7-14 günlük gerçek CPU/bellek kullanımını topla.
2. Öner: KRR veya VPA ile P95/P99 tabanlı request önerisi al.
3. Uygula: Request’i gerçek kullanımın biraz üstüne, limiti güvenli tampona ayarla.
4. Doğrula: OOMKill ve CPU throttling metriklerini izle, gerekirse ince ayar yap.

Right-sizing’in en kritik incelikleri request ile limit arasındaki ayrımda gizlidir. CPU sıkıştırılabilir (compressible) bir kaynaktır: limit aşıldığında pod öldürülmez, yalnızca throttle edilir, yani yavaşlar. Bellek ise sıkıştırılamaz; bellek limiti aşıldığında pod anında OOMKill ile sonlandırılır. Bu fark, boyutlandırma stratejisini doğrudan belirler. Bellek isteği ve limiti, gerçek kullanımın P99’una güvenli bir tampon eklenerek ayarlanır; çünkü buradaki hata pod çökmesi demektir. CPU tarafında ise birçok olgun ekip CPU limitini tamamen kaldırır ve yalnızca request tanımlar; çünkü CPU limiti, node’da boşta kapasite olsa bile pod’u gereksiz throttle ederek gecikme yaratabilir. Doğru kurgu, request’i gerçek kullanımın P95’ine yakın, belleği güvenli tamponlu, CPU limitini ise iş yükünün hassasiyetine göre ayarlamaktır. Bu ayar tek seferlik değildir; iş yükü deseni değiştikçe KRR raporları periyodik gözden geçirilir.

Detaylı boyutlandırma için VPA, Goldilocks ve KRR ile sağ boyutlandırma rehberi adım adım ilerler. Boyutlandırma sonrası node ölçeklemesini Karpenter ve Cluster Autoscaler tamamlar.

Bin Packing: Pod Yoğunluğunu Artırma

Bin packing, pod’ları mümkün olan en az node’a verimli sığdırma sanatıdır. Varsayılan Kubernetes scheduler dengeli dağıtıma meyillidir; bu, maliyet için ideal değildir. MostAllocated puanlama stratejisi veya Karpenter konsolidasyonu, dolu node’ları tercih ederek boş node’ları kapatmaya zemin hazırlar.

Bin packing’in mantığı basittir ama etkisi büyüktür: varsayılan scheduler pod’ları node’lara dengeli dağıttığında, her node yarı dolu kalır ve hiçbiri kapatılamaz. MostAllocated stratejisi ise pod’ları önce dolu node’lara yerleştirir, böylece bazı node’lar tamamen boşalır ve otomatik ölçekleyici (Karpenter veya Cluster Autoscaler) bu boş node’ları sonlandırır. Örneğin on adet yarı dolu node, doğru paketlemeyle altı dolu node’a indirgenebilir; bu, doğrudan dört node’luk bir fatura tasarrufudur. Karpenter’ın konsolidasyon özelliği bu süreci sürekli yürütür: trafik düştüğünde pod’ları daha az node’a toplar, arttığında yenilerini saniyeler içinde sağlar.

Bin packing’i agresif uygularken Pod Disruption Budget (PDB) tanımlamak şarttır; aksi halde konsolidasyon kritik pod’ları aynı anda taşıyıp kesinti yaratır. PDB, bir uygulamanın aynı anda kaç replikasının kesintiye uğrayabileceğine bir alt sınır koyar; örneğin üç replikalı bir servis için “en az iki replika her zaman ayakta kalsın” kuralı, konsolidasyonun tüm replikaları aynı anda taşımasını engeller. Bunun yanına do-not-disrupt anotasyonu eklenerek, taşınması özellikle riskli olan durumlu (stateful) pod’lar konsolidasyon dışı bırakılır. Bu güvenlik mekanizmaları olmadan agresif bin packing, maliyet tasarrufunu erişilebilirlik kaybına çevirir.

Spot Instance ve Karpenter ile Birim Maliyeti Düşürme

Spot instance, bulut sağlayıcının atıl kapasitesini on-demand fiyatın %60-90 altında sunar. Kesintiye dayanıklı, durumsuz (stateless) iş yükleri için en büyük tek tasarruf kalemidir. Karpenter, ihtiyaca göre en ucuz uygun node tipini saniyeler içinde sağlar ve spot kesintilerinde otomatik yeniden yerleştirir.

• Stateless iş yükleri → spot: Web sunucuları, batch işleri, CI runner’ları spot’ta çalışır.
• Stateful / kritik → on-demand: Veritabanları ve durumlu servisler on-demand veya reserved kalır.
• Karşılama (graceful drain): Spot kesinti uyarısında Karpenter pod’ları yeni node’a taşır.
• Diversifikasyon: Birden çok instance tipi tanımlanır, tek havuz tükenince diğerine geçilir.

Spot temelli zamanlama için Karpenter ile spot instance iş yükü zamanlama derinlemesine ilerler. Karpenter resmi dokümantasyonu konsolidasyon ve provisioner yapılandırmasını ayrıntılı anlatır.

En etkili strateji karma kullanımdır: tahmin edilebilir taban yükü Savings Plan veya Reserved ile, değişken ve durumsuz yükü spot ile karşılayıp Karpenter’a en uygun node seçimini bırakmak birim maliyeti belirgin düşürür.

FinOps ve Maliyet Gözlemlenebilirliği

Optimizasyon tek seferlik değil, sürekli bir disiplindir. Maliyeti namespace, takım ve iş yükü düzeyinde görünür kılmak (showback/chargeback) olmadan israf tekrar birikir. OpenCost (CNCF projesi) ve Kubecost, pod düzeyinde maliyet dağılımını gerçek zamanlı raporlar.

Maliyet politikalarını zorlamak için GitOps ile politika yönetimi request/limit kurallarını kod olarak garanti eder.

Otomatik Ölçekleme Katmanları: HPA, VPA ve Olay Tabanlı

Maliyet optimizasyonunun sürdürülebilir olması, doğru ölçekleme katmanlarının birlikte çalışmasına bağlıdır. Kubernetes’te üç farklı ölçekleme ekseni vardır ve bunları karıştırmak maliyet ve kararlılık sorunlarına yol açar. Yatay pod ölçekleyici (HPA) yük arttığında replika sayısını artırır, azaldığında düşürür; bu, değişken trafikli stateless servislerde atıl kapasiteyi en aza indirir çünkü kapasite talebe göre nefes alıp verir. Dikey pod ölçekleyici (VPA) ise replika sayısını değil, pod başına request değerini ayarlar; tek replikalı veya yatay ölçeklenemeyen iş yükleri için doğru boyutu sağlar. Kritik bir kural, HPA ile VPA’yı aynı metrik (CPU) üzerinde aynı anda kullanmamaktır; ikisi birbirini sürekli tetikleyerek çakışır.

Üçüncü eksen olay tabanlı ölçeklemedir: KEDA gibi araçlar, CPU yerine bir kuyruk uzunluğu, mesaj broker derinliği veya özel bir iş metriğine göre ölçekler. Bu, batch ve asenkron iş yüklerinde kritik bir kazanç sağlar; örneğin bir kuyruk boşaldığında işçi pod’larını sıfıra (scale-to-zero) indirerek hiç iş yokken hiç maliyet üretmemesini mümkün kılar. Üretim dışı ortamlarda bu sıfıra ölçekleme, gece ve hafta sonu maliyetini neredeyse tamamen ortadan kaldırır. Doğru kurgu, bu üç katmanı iş yükünün doğasına göre eşleştirir: değişken trafikli web servisleri için HPA, tek replikalı arka plan servisleri için VPA, kuyruk güdümlü işçiler için KEDA. Bu katmanların altında ise node ölçekleyici (Karpenter) çalışır ve pod talebine göre node’ları sağlar veya kapatır; böylece pod düzeyindeki ölçekleme doğrudan node faturasına yansır.

Tipik Sorunlar ve Çözümleri

Maliyet optimizasyonu agresif uygulandığında performans ve erişilebilirlik riskleri doğar. En sık karşılaşılan sorunlar ve çözümleri:

• Aşırı right-sizing → OOMKill: Bellek isteği fazla kısılınca pod çöker. Çözüm: P99 tabanlı öneri kullan, bellek limitine güvenli tampon bırak.
• Spot kesintisi → servis düşmesi: Spot node aniden geri çekilir. Çözüm: PDB tanımla, kritik iş yükünü on-demand’da tut, diversifikasyon uygula.
• CPU throttling: CPU limiti düşük, uygulama yavaşlar. Çözüm: limiti kaldır veya yükselt, request’i doğru ayarla.
• Konsolidasyon kaosu: Karpenter pod’ları sürekli taşıyıp kesinti yaratır. Çözüm: konsolidasyon politikasını WhenEmpty ile sınırla, do-not-disrupt anotasyonu kullan.
• Orphan kaynak birikimi: Eski PV ve LB faturayı şişirir. Çözüm: düzenli maliyet denetimi ve otomatik temizleme job’ı.
• Tasarruf geri tepmesi: Boyut düşürülünce performans düşer, müşteri etkilenir. Çözüm: değişiklikleri kademeli uygula, SLO’ları izle, gerekirse geri al.

Sonuç ve Öneriler

Kubernetes maliyet optimizasyonu üç katmanda en yüksek getiriyi verir: önce right-sizing ile aşırı rezervasyonu sil (KRR/VPA, %20-40 kazanç), sonra bin packing ile pod yoğunluğunu artır ve idle node’ları kapat (%15-30), ardından spot instance ile birim fiyatı %60-90 düşür. Bu adımlar tek seferlik değil, FinOps disipliniyle sürekli yürütülür: OpenCost ile görünürlük, GitOps ile politika zorlaması, SLO izlemesiyle güvenlik ağı. Agresif tasarruf performansı tehdit edebilir; bu yüzden her değişikliği kademeli uygulayın, PDB ile koruyun ve P99 metriklerini izleyin. Doğru kurgulandığında tipik bir kümede compute faturasının yarısından fazlası geri kazanılabilir.

Sıkça Sorulan Sorular