Kubernetes Cost Optimization: Resource Limit ve VPA, HPA Stratejisi

CNCF 2025 FinOps for Kubernetes raporuna göre kurumsal kümelerin %68’i rezerve ettiği CPU’nun yalnızca %35’ini, RAM’in ise %41’ini gerçekten kullanıyor; geri kalan %59-65’lik dilim doğrudan bulut faturasına yansıyan israf. Kubecost State of Kubernetes Cost 2025 raporu, ortalama bir üretim kümesinin aylık 38.400 USD harcamasının 17.900 USD’sinin (yaklaşık %47) yanlış yapılandırılmış request/limit ve devre dışı autoscaler kaynaklı olduğunu ortaya koyuyor. Cast.AI 2026 Cloud Cost Optimization Report’a göre HPA, VPA, Cluster Autoscaler ve Karpenter’ın doğru kombinasyonu yıllık OPEX’te %52-63 düşüş, payback süresinde 4.1 ay sonuç veriyor. 2026’da CTO’nun masasındaki soru artık “Kubernetes’e geçelim mi” değil; “neden bu kadar pahalı ve nasıl yarıya indireceğiz”.

Bu rehberde Kubernetes cost optimization disiplininin dört direği olan resource request/limit hesaplaması, HPA + VPA + Cluster Autoscaler + Karpenter dörtlüsünün doğru orkestrasyon paterni, bin packing ve spot/on-demand node pool karışımı, ayrıca Goldilocks, Kubecost, Cast.AI, PerfectScale, StormForge gibi right-sizing araçlarının seçim kriterlerini ele alıyoruz. Docker ve Kubernetes yönetimi temellerini tamamladıysanız, bu yazı maliyet katmanını mühendislik disiplinine dönüştürmek için kullanabileceğiniz somut bir 2026 playbook’u sunuyor.

Kubernetes Cost Optimization 2026: Neden Fatura Şişiyor?

Kubernetes cost optimization meselesinin kökünde üç yapısal sorun var: aşırı tahmin edilmiş request değerleri, sabit replica sayıları ve namespace düzeyinde görünürlük eksikliği. Cast.AI 2026 raporu üretim kümelerinde CPU request/usage oranının ortalama 3.4x, memory için 2.1x olduğunu, başka bir deyişle her 1 vCPU gerçek kullanıma karşılık 3.4 vCPU bedava rezerve edildiğini gösteriyor. PerfectScale 2025 anketi geliştiricilerin %72’sinin request değerini “patlama olur diye” 2-3 katına çıkardığını, kimsenin geri dönüp ölçmediğini raporluyor.

İkinci sorun replica sabitleme: HPA yapılandırılmamış deployment’lar minimum 3 pod ile 7/24 çalışıyor, gece trafiği düşse bile küme küçülmüyor. Üçüncü sorun ise hesaplaşma: FinOps disiplini kurulmadığında her ekip “benim payım küçüktür” varsayımıyla davranıyor, Kubecost veya OpenCost showback panosu olmadan namespace başına maliyet kara kutu kalıyor.

• Over-provisioning: Geliştiriciler request’i ölçüm yerine “gönül rahatlığıyla” belirliyor; ortalama 3.4x şişme.
• Sabit replica: HPA devre dışıyken min 3 pod, gece trafiği %20’de olsa bile küçülme yok.
• Idle node: Cluster Autoscaler veya Karpenter kapalıyken kullanılmayan node’lar 7/24 fatura yazıyor.
• Orphan PVC: Silinen pod’lardan kalan EBS/Azure Disk volume’leri sessizce birikmeye devam ediyor.
• Görünürlük yok: Showback panosu olmadan hangi ekibin hangi maliyeti ürettiği bilinmiyor.
• Yanlış instance ailesi: Memory-bound iş yükü CPU-optimize node’a, CPU-bound yük ise memory-optimize node’a düşüyor.

Resource Request ve Limit: Doğru Değerin Mühendisliği

Request scheduler’ın node seçerken kullandığı garanti edilen kaynak ayırma; limit ise pod’un asla aşamayacağı tavan. Google SRE ekibinin yayınladığı pratiğe göre CPU için limit konulmaması, memory için limit konulması en sağlıklı yaklaşım: çünkü CPU throttle edilir ama servis devam eder, memory ise OOMKill üretir ve pod restart olur. Prometheus + kube-state-metrics ile son 14 günün p95 değerini alıp %15 buffer eklemek 2026 endüstri standardıdır.

Kaynak	Request Önerisi	Limit Önerisi	Risk	Doğrulama
CPU (web/API)	p95 + %15	Konulmaz (CPU throttle)	Burst kapasitesi kaybı	VPA Recommend p95
CPU (batch/ML)	p99	p99 × 1.5	Yarış koşulu	StormForge ML profili
Memory (stateless)	p95 × 1.1	Request × 1.25 (OOMKill koruması)	OOMKill restart	Goldilocks 7 gün
Memory (Java/JVM)	Heap + 30%	Request × 1.15	GC pressure	Heap dump + jstat
Ephemeral storage	İz büyüklüğü × 2	Pod eviction’a karşı korumalı	Disk pressure	kubelet metrics

Datadog 2025 Container Report, request değerlerini p95’e kalibre eden ekiplerin küme node sayısını ortalama %38 azalttığını gösteriyor. Önemli olan ölçüm penceresi: gece+gündüz, hafta sonu+hafta içi karışımı en az 14 gün olmalı, aksi hâlde haftalık periyodik yükler kaçırılır. Spinnaker veya ArgoCD üzerinden uygulanan canary deploy’larda yeni request/limit değerini önce %10 trafiğe almak, OOMKill riskini görmeden production’a yaymanın temel hijyenidir.

• Ölçüm penceresi: Minimum 14 gün, ideal 28 gün (aylık periyodik yükleri yakalar).
• İstatistik: p95 (web/API), p99 (batch), max (memory limit hesabı için).
• Buffer: CPU %15, memory %25 ek pay (OOMKill koruması için memory daha yüksek).
• Validation: Canary %10 trafik + 24 saat gözlem önce, sonra %50, sonra tam yayılım.
• Rollback: ArgoCD rollback prosedürü hazır olsun; yanlış limit OOMKill furtunası üretebilir.

HPA, VPA, Cluster Autoscaler ve Karpenter: Hangisi Ne İçin?

Dört autoscaler aynı kümede bir arada yaşar ama farklı katmanları yönetir: HPA yatay (pod sayısı), VPA dikey (pod boyutu), Cluster Autoscaler/Karpenter ise node katmanı. AWS Karpenter v1.0 (2024 sonu GA, 2025 boyunca yaygınlaştı) Cluster Autoscaler’ın iki temel sorununu çözdü: node pool tanımı yerine “her pod için en uygun instance’ı seç” yaklaşımı ve 60 saniyenin altında provisioning. Cast.AI 2026 raporu Karpenter geçişinin EKS kümelerinde ortalama %23 ek tasarruf yarattığını gösteriyor.

Autoscaler	Ne Ölçeklendirir	İdeal Yük	Reaksiyon Süresi	Restart Riski	Maliyet Etkisi
HPA (CPU/Memory)	Pod sayısı	Stateless API, web frontend	30-60 sn	Yok	%30-45 düşüş
HPA (custom/RPS)	Pod sayısı	Latency-sensitive API	15-45 sn	Yok	%35-50 düşüş
VPA (Auto mode)	Request/limit	Batch, ML inference	5-15 dk	Var (pod evict)	%40-55 düşüş
VPA (Recommend)	Sadece öneri (PR)	Üretim, stateful	Manuel	Yok	%25-40 (uygulamayla)
KEDA	Pod sayısı (event-driven)	Kafka tüketici, kuyruk, cron	5-30 sn	Yok	%50-70 düşüş
Cluster Autoscaler	Node sayısı (pool bazlı)	Sabit instance aileli kümeler	2-5 dk	Drain riski	%25-40 düşüş
Karpenter v1	Node sayısı + tip	Heterojen yük, spot karışım	30-90 sn	Disruption budget kontrollü	%40-55 düşüş

En kritik anti-pattern: HPA ve VPA’nın aynı metrik üzerinden aynı deployment’a uygulanması. CPU bazlı HPA + CPU bazlı VPA çakışır, salınım yaratır ve sonunda her ikisi de geri çekilir. Doğru patern: HPA CPU veya RPS’e bakar, VPA sadece memory’e bakar ya da Recommend modunda kalır ve önerileri ArgoCD üzerinden PR olarak ekiplere düşer. GitOps tabanlı ArgoCD/Flux mimarisi bu PR akışını otomatize eder.

Right-Sizing Araçları: Goldilocks, Kubecost, Cast.AI, PerfectScale, StormForge

Right-sizing manuel yapıldığında 200 deployment üzeri kümelerde sürdürülemez bir yük üretir; bu yüzden 2026’da seçim “araç var mı yok mu” değil “hangi araç hangi olgunluk seviyesine uygun”. Goldilocks (Fairwinds) ücretsiz açık kaynak başlangıç, Kubecost showback + öneri, Cast.AI ve PerfectScale tam otomatik right-sizing, StormForge ise ML tabanlı performans + maliyet optimizasyonu sunar.

Araç	Model	Otomasyon	Maliyet (aylık)	İdeal Profil	Güçlü Yön
Goldilocks	Açık kaynak (Fairwinds)	Sadece öneri (VPA wrapper)	0 USD	Küçük-orta küme, başlangıç	Dakikalar içinde kurulum
Kubecost / OpenCost	Açık kaynak + Enterprise	Öneri + showback	0-1.500 USD	FinOps showback gereksinimi	Namespace allocation, multi-cloud
Cast.AI	SaaS (commercial)	Tam otomatik (rebalancer)	%3-5 tasarrufun	EKS/GKE/AKS, hızlı ROI	Node provisioning + spot otomasyonu
PerfectScale	SaaS	Yarı-otomatik öneri	İstek bazlı	SRE-driven, audit dostu	Reliability + cost dengeli
StormForge	SaaS, ML tabanlı	Otomatik (ML opt.)	Enterprise	Performans + cost birleşimi	ML ile yük profili öğrenme

Pratik karar: 0-50 deployment kümede Goldilocks + OpenCost yeterli. 50-300 deployment aralığında Kubecost Enterprise + manuel apply (GitOps PR ile) en iyi maliyet/değer. 300+ deployment ve heterojen yük varsa Cast.AI veya StormForge tam otomatik right-sizing yatırımı 6 ay içinde geri ödüyor. Resmi karşılaştırma için Kubecost blogundaki State of Kubernetes Cost ve Cast.AI 2026 Cloud Cost Optimization Report baseline verisi olarak kullanılabilir.

Bin Packing: Aynı Node’da Daha Çok Pod, Daha Az Fatura

Bin packing, scheduler’ın pod’ları boş node yaratmak yerine mevcut node’ları daha doluya getirecek şekilde yerleştirmesi disiplinidir. Kubernetes default scheduler “LeastAllocated” (yükü dağıt) ile “MostAllocated” (yükü topla) arasında plugin yapılandırmasıyla seçim yapar. Karpenter v1 varsayılan olarak MostAllocated benzeri davranır ve consolidation feature’ı ile boşalan node’ları otomatik kapatır.

Strateji	Scheduler/Tool	Etki	Risk	Önerilen Yük
MostAllocated scoring	kube-scheduler plugin	Node sayısı %15-25 azalır	Tek node arızasında daha çok pod düşer	Stateless API, batch
Karpenter consolidation	Karpenter v1	Idle node otomatik kapanır	Disruption budget gerekli	Heterojen yük
Pod topology spread	kube-scheduler	Bölge/AZ dengeli + dolu node	Karmaşıklık artar	HA gerektiren prod
Descheduler	kubernetes-sigs/descheduler	Yanlış yerleşmiş pod’lar yeniden dağıtılır	Yeniden başlatma penceresi	Uzun ömürlü deployment
NodeLocal pinning	Affinity/Taint	GPU/ARM pool’lar verimli	Esneklik kaybı	GPU ML inference

Karpenter consolidation 2025 boyunca olgunlaştı ve disruption budget ile birleştiğinde stateful yüklerde bile kullanılabilir hale geldi. Resmi belgeler karpenter.sh dokümantasyonunda “consolidationPolicy: WhenEmptyOrUnderutilized” parametresini öneriyor; bu ayar tek başına EKS faturasında %15-20 ek tasarruf sağlayabiliyor.

Spot, On-Demand ve Reserved: Doğru Node Pool Karışımı

2026 itibarıyla AWS EC2 Spot iskonto oranı on-demand’a göre ortalama %72, Azure Spot %68, GCP Spot %71 seviyesinde. Ancak spot tek başına çözüm değil: SLA gerektiren ödeme veya kimlik doğrulama servisleri spot’a alınamaz. Doğru yaklaşım üç katmanlı bir karışım: Spot (stateless + batch), On-demand (kritik stateful), Reserved/Savings Plan (baseline kapasite).

Node Tipi	İskonto	Kesinti Riski	İdeal Yük	Yıllık Tasarruf
On-demand	0 (baseline)	Yok	Ödeme, auth, DB primary	0
Reserved (1-yıl)	%30-40	Yok (taahhüt)	Baseline kapasite	%30-40
Savings Plan (3-yıl)	%50-60	Yok (esnek taahhüt)	Çok yıllık platform	%50-60
Spot (AWS EC2)	%72 ort.	2 dk uyarıyla kesinti	Stateless API, batch, CI	%60-90
Spot + Karpenter	%72-85	Otomatik replacement	Heterojen küme	%65-92

Karpenter veya Cluster Autoscaler ile entegre spot interruption handler kullanıldığında pod migration süresi 2 dakikanın altına iniyor ve SLA %99.9 seviyesinde korunabiliyor. Stateless web/API’leri spot’a, DB primary’leri on-demand’a, baseline kapasiteyi Savings Plan’a vermek 2026’da en olgun karışım. Yönetilen container PaaS alternatiflerinde spot orkestrasyon platforma devredilir, ama esneklik düşer.

• Spot’a uygun: Stateless API, batch worker, CI runner, web frontend, image processing.
• On-demand kalmalı: Ödeme servisi, OAuth provider, DB primary, mesaj kuyruğu broker.
• Reserved/Savings Plan: Baseline kapasite (24/7 minimum yük), platform kontrolcüleri, ingress controller.
• Asla spot’a verme: Etcd, Vault primary, durum biriktiren WebSocket sunucusu.

FinOps Döngüsü: Inform, Optimize, Operate

FinOps Foundation’ın 2025 Kubernetes işbirliği belgesi maliyet optimizasyonunu üç fazlı bir döngü olarak tanımlıyor: Inform (görünürlük), Optimize (right-size + autoscale + spot), Operate (sürekli iyileştirme + KPI). Bu döngü tek seferlik audit değil, aylık ritimde işleyen mühendislik disiplinidir. Resmi referans FinOps Foundation Kubernetes projesinde erişilebilir.

1. Inform: OpenCost veya Kubecost ile namespace, label ve deployment başına maliyet panosu kur; Goldilocks ile request önerileri görünür hâle gelsin.
2. Allocate (Showback): Her ekibe kendi namespace faturasını haftalık raporla göster; sahiplik hissi maliyetin yarısını çözer.
3. Right-size: VPA Recommend çıktısını ArgoCD PR’ı olarak ekiplere aç; manuel apply yerine GitOps gözden geçirme süreci.
4. Autoscale: HPA min replica 2, hedef CPU %70; KEDA ile event-driven yükleri sıfıra kadar indir.
5. Spot/Savings Plan: Stateless yükleri spot node pool’a, baseline kapasiteyi 1-3 yıllık Savings Plan’a taşı.
6. Operate: Aylık FinOps toplantısı; KPI’lar cost/request, request:usage oranı, idle cost yüzdesi.
7. Iterate: StormForge veya Cast.AI gibi ML araçlarıyla sürekli kalibrasyon; her ay %3-5 ek tasarruf hedefi.

GitOps Cost Guardrails: ArgoCD ve OPA ile Önleyici Politikalar

Optimize edilmiş bir kümenin tekrar şişmesinin önüne geçmenin en etkili yolu maliyet politikalarını GitOps katmanına gömmektir. ArgoCD veya Flux ile uygulanan deployment’lar OPA Gatekeeper veya Kyverno üzerinden geçirildiğinde “request’siz pod merge edilemez”, “limit ratio 4x’i aşamaz”, “spot taint’siz pod prod namespace’ine giremez” gibi guardrails önleyici çalışır.

Politika	Aracı	Etki	Uygulama Noktası
Request zorunlu	Kyverno / Gatekeeper	%30 over-allocation engellenir	Admission webhook
Limit:Request ≤ 4x	OPA Rego policy	Bursting istismarı engellenir	CI + admission
Spot taint zorunlu	Karpenter NodePool	Stateful pod spot’a düşmez	Scheduler
Topology spread	kube-scheduler	HA garantili bin packing	Pod spec
HPA zorunlu	Kyverno mutate	Yeni deployment otomatik HPA alır	GitOps PR
Cost label zorunlu	Gatekeeper validate	Showback %100 kapsamlı	Admission

Cilium ile mikrosegmentasyon ve container güvenliği guardrails’leri ile birlikte uygulandığında, FinOps disiplini güvenlik ve maliyet politikalarının aynı admission katmanından geçtiği tek bir kontrol düzlemine kavuşur.

FinOps Raporlama ve KPI Yönetimi: Neyi Ölçeceğiz?

Ölçülmeyen israf optimize edilemez; ölçülen ama paylaşılmayan rapor da değişim yaratmaz. Kubecost State of Kubernetes Cost 2025 raporu olgun FinOps ekiplerinin sadece 4-5 KPI’a odaklandığını gösteriyor. Önemli olan metrik sayısını arttırmak değil, doğru üç-beş metriği aylık ritimle ekipler arası paylaşmak.

KPI	Hedef	Ölçüm Aracı	Sahibi	Frekans
Cost per request (USD/1000)	↓ %10 çeyrekte	Kubecost + Prometheus	Platform + ekip	Haftalık
Request:Usage oranı (CPU)	1.3-1.5	VPA Recommender	Ekip	Haftalık
Idle cost yüzdesi	< %15	Kubecost allocation	Platform	Aylık
Spot adoption oranı	> %50 (uygun yüklerde)	Karpenter + Cast.AI	Platform	Aylık
Showback kapsamı	%100 namespace	Cost label policy	FinOps	Aylık
Cluster utilization	%65-75	kube-state-metrics	Platform	Haftalık

Cost per request en demokratik metrik: ekipler kendi servislerinin verimliliğini kendileriyle kıyaslar, vendor kıyaslamasına ihtiyaç duymaz. PerfectScale’in açık raporu perfectscale.io/blog üzerinde benchmark verisi sağlıyor. Multi-cloud stratejisi izleyen kurumlarda KPI’ların bulut başına ayrıştırılması, vendor lock-in riskini görünür kılar.

Maliyet, ROI ve Sınırlamalar: 2026 Gerçek Rakamlar

Forrester TEI 2025 çalışmasına göre 200 node üzeri kümelerde FinOps + autoscaler + Karpenter + spot kombinasyonu 12 aylık dönemde ortalama %52 OPEX azaltıyor; payback süresi 4.1 ay. Cast.AI 2026 raporu otomatik right-sizing eklendiğinde rakamın %63’e çıktığını gösteriyor. Ancak sınırlamalar da net: VPA Auto modu stateful workload’larda pod restart ürettiği için Kafka, PostgreSQL, Istio kontrol düzlemi gibi servislerde sadece Recommend modu tercih edilmeli. Spot node’lar SLA gerektiren ödeme servisleri için uygun değil; bu yüklerde 1-3 yıllık Savings Plan %30-60 indirimle daha sağlıklı.

Bir diğer dikkat noktası araç maliyeti: Cast.AI veya StormForge’un fee’si (tasarrufun %3-5’i) tasarrufun altında kalıyorsa devam edin, eşiğe yaklaşıyorsa OpenCost + Goldilocks + manuel GitOps ile içselleştirilebilir. 0-50 deployment kümede araç fee’sinin geri ödenmesi 12 ayı aşabiliyor; bu durumda açık kaynak stack daha doğru karar.

Üçüncü kritik sınırlama Cilium gibi eBPF tabanlı CNI’ların maliyet etkisi: Cilium 2025 sürümleri “bandwidth manager” ve “L7 LB” özellikleriyle Istio/Envoy ihtiyacını azaltabildiği için service mesh fee’sinin %30-40’ını tasarruf yaratıyor; ancak bu kazancın FinOps tablosuna eklenmesi için cost label’ların network katmanına kadar uzatılması gerekiyor. Son olarak unutulmaması gereken bir nokta: optimizasyon sonrası 6 ay boyunca her ay 5 yeni deployment eklendiğinde regression görülmesi tipiktir; bu yüzden Kyverno tabanlı admission policy’leri “yeni deployment HPA + cost label zorunlu” kuralıyla yapılandırmak, kazanımın erimesini önleyen tek sürdürülebilir yöntemdir.

Sık Sorulan Sorular

Sonuç: 2026 Kubernetes Maliyet Stratejisi

Kubernetes cost optimization tek seferlik bir audit değil, sürekli işleyen bir FinOps disiplinidir. 2026 verdict net: resource request’lerin Prometheus p95 + %15 buffer’a kalibrasyonu, HPA + VPA Recommend + Karpenter consolidation üçlüsünün doğru orkestrasyonu, KEDA ile event-driven sıfıra inebilen yükler, spot + Savings Plan + on-demand üç katmanlı node pool karışımı ve GitOps üzerinden uygulanan OPA/Kyverno guardrails birleştiğinde bulut faturasında %47-63 düşüş gerçekçi bir hedef. Önerilen başlangıç: Goldilocks + OpenCost ile görünürlük kur, 60 gün sonra Kubecost Enterprise veya Cast.AI değerlendir, 90 gün sonra Karpenter consolidation aktive et. Ölçülmeyen israf optimize edilemez; ölçülen ama showback’le paylaşılmayan rapor da değişim yaratmaz.