- 01Kubernetes maliyeti yalnız node compute değildir; storage, network, load balancer, observability ve operasyon maliyetleri birlikte değerlendirilmelidir.
- 02Scheduler Pod yerleşimini resource request değerlerine göre yapar; gereğinden yüksek request değerleri node kapasitesinin boş kalmasına ve gereksiz node ihtiyacına yol açabilir.
- 03Workload autoscaling ile node autoscaling birlikte çalışmalı; yanlış request, minimum replica veya scheduling constraint autoscaler tasarrufunu sınırlayabilir.
- 04Maliyet optimizasyonunda önce görünürlük ve rightsizing, sonra autoscaling, storage/network cleanup ve pricing modeli değerlendirilmelidir.
- 05Kubernetes cost optimization production kapasitesi, SLO ve workload davranışıyla birlikte yapılmalıdır.
Kısaca
Kubernetes maliyeti yalnız worker node fiyatından oluşmaz. Toplam maliyet; node compute, persistent storage, load balancer, data transfer, monitoring/logging ve platform operasyonunun birleşimidir. En büyük israf kaynaklarından biri gerçek kullanımdan kopuk resource request değerleridir. Dynamis Teknoloji, Kubernetes maliyet optimizasyonunu önce workload görünürlüğü ve rightsizing, sonra autoscaling ve kapasite modeli üzerinden ele alır.
Kubernetes maliyetini hangi kalemler oluşturur?
Bir production Kubernetes cluster'ında maliyet tipik olarak şu katmanlardan oluşur:
- worker node compute
- control plane veya managed Kubernetes hizmeti
- persistent volume / block storage
- object storage
- load balancer
- public IP ve network servisleri
- internet ve region'lar arası data transfer
- container registry
- logging ve metrics
- backup
- security araçları
- operasyon ve incident response
Aynı uygulama üç büyük node, altı küçük node veya autoscaling ile değişken node sayısında farklı maliyet ve dayanıklılık profili oluşturabilir.
En büyük maliyet kalemi çoğu zaman node kapasitesidir
Managed Kubernetes servislerinde uygulamalar worker node'lar üzerinde çalışır. Bu node'lar sanal makine, bare metal veya kesintiye toleranslı workload'larda spot kapasite olabilir.
Yalnız toplam vCPU ve RAM'e bakmak yeterli değildir. Şunları birlikte değerlendirin:
- Kaç node sürekli açık?
- Ortalama CPU ve memory kullanımı ne?
- Node üzerinde schedulable fakat boş kapasite ne kadar?
- Hangi workload büyük request yüzünden packing'i bozuyor?
- Minimum node sayısı gerçekten gerekli mi?
- Failure domain ve high availability için kaç node zorunlu?
Cluster yüzde 25 gerçek CPU kullanırken yüzde 80 kapasiteyi request olarak ayırıyorsa fiziksel olarak dolu görünen cluster ekonomik olarak verimsiz olabilir.
Resource request ile gerçek kullanım arasındaki fark maliyeti belirler
Kubernetes scheduler Pod'ları node'lara yerleştirirken container resource request değerlerini kullanır.
Örneğin bir Pod için CPU request 2 vCPU ve memory request 4 GiB tanımlandıysa scheduler bu kapasiteyi yerleşim hesabında ayrılmış kabul eder. Uygulama gerçekte 300m CPU ve 900 MiB RAM kullanıyor olabilir.
Bu fark onlarca workload'da birleştiğinde yeni node ihtiyacı yaratabilir.
Kubernetes dokümantasyonuna göre request değerleri scheduler'ın Pod'u hangi node'a yerleştireceğini belirlemesinde kullanılır; limit ise container'ın kullanabileceği kaynak üst sınırını kontrol eder.
Bu nedenle ilk soru şudur:
Request değerlerimiz gerçek kullanım trendine ne kadar yakın?
Request'i çok düşürmek de doğru değildir
Kubernetes maliyet optimizasyonu tüm request'leri küçültmek değildir.
Gereğinden düşük request:
- node overcommit'i artırabilir
- CPU contention yaratabilir
- memory pressure oluşturabilir
- eviction riskini artırabilir
- application latency'yi bozabilir
- autoscaling davranışını etkileyebilir
Production rightsizing uzun dönemli metrik ve peak kullanım bilgisiyle yapılmalıdır.
Bakılabilecek metrikler:
- p50 ve p95 CPU
- peak CPU
- p50 ve p95 memory
- OOM event
- CPU throttling
- restart
- request / usage ratio
Tek bir anlık kullanım çıktısıyla production request değiştirmeyin.
Node utilization nasıl ölçülmeli?
Node başına yalnız CPU usage bakmak yeterli değildir.
Örnek:
| Metrik | Değer |
|---|---|
| Kapasite | 8 vCPU / 32 GiB |
| Pod CPU request toplamı | 6.8 vCPU |
| Gerçek ortalama CPU | 2.1 vCPU |
| Pod memory request toplamı | 25 GiB |
| Gerçek ortalama memory | 12 GiB |
Scheduler açısından node büyük ölçüde doludur. Gerçek kullanım açısından ise ciddi boş kapasite vardır.
İzlenecek sıra:
- En yüksek request/usage farkı olan workload'ları bulun.
- Peak kullanım ve SLO'yu kontrol edin.
- Request değerlerini kontrollü biçimde düşürün.
- Pod packing'in iyileşip iyileşmediğini gözlemleyin.
- Fazla node konsolide edilebiliyor mu kontrol edin.
Vertical Pod Autoscaler rightsizing için nasıl kullanılabilir?
Kubernetes Vertical Pod Autoscaler, workload geçmiş ve güncel kullanımını analiz ederek resource request önerileri üretebilir.
VPA CPU ve memory kullanımı ile geçmiş trendleri değerlendirerek rightsizing önerisi üretir. Production ortamında önce önerileri gözlemlemek ve kritik workload'larda kademeli uygulamak daha güvenli olabilir.
Kubernetes dokümantasyonu VPA'nın request değerlerini gerçek kullanım verilerine göre ayarlayarak resource waste'i azaltmaya yardımcı olabileceğini belirtir.
Horizontal Pod Autoscaler maliyeti hem artırabilir hem azaltabilir
Horizontal Pod Autoscaler workload replica sayısını metriklere göre değiştirir.
Trafik artınca replica sayısı yükselir, trafik düşünce gereksiz replica'lar azaltılabilir.
Ancak yanlış ayar maliyeti artırabilir:
- minimum replica gereğinden yüksek
- CPU target gereğinden düşük
- yanlış metric kullanılıyor
- her Pod gereğinden büyük request taşıyor
Bu nedenle workload autoscaling + doğru request + node autoscaling birlikte çalışmalıdır.
Node autoscaling ne zaman maliyet düşürür?
Node autoscaling, schedulable Pod ihtiyacına göre node ekleyip gereksiz node'ları konsolide etmeye yardımcı olur.
Kubernetes dokümantasyonu node autoscaling'in workload ihtiyacına göre altyapıyı dinamik provision edip konsolide ederek kapasite ve maliyet optimizasyonu sağlayabileceğini belirtir.
Tasarruf şu durumlarda sınırlanabilir:
- minimum node sayısı çok yüksek
- PodDisruptionBudget node drain'i engelliyor
- DaemonSet overhead yüksek
- topology constraint çok katı
- Pod request fazla yüksek
- local storage node removal'ı engelliyor
- instance tipi workload dağılımına uymuyor
Autoscaler yalnız tanımlanan constraint'ler içinde çalışabilir.
Küçük node mu büyük node mu?
Tek doğru cevap yoktur.
Daha büyük node daha az node operasyonu ve daha düşük DaemonSet overhead oranı sağlayabilir; ancak failure blast radius ve boş kapasite maliyeti büyüyebilir.
Daha küçük node kapasiteyi daha küçük adımlarla ölçeklemeyi kolaylaştırabilir; ancak node sayısı ve platform overhead'i artabilir.
Doğru node tipi workload request dağılımıyla birlikte seçilmelidir.
Storage, load balancer ve network maliyetini unutmayın
Unused PersistentVolume kaynakları, eski StatefulSet volume'ları, gereksiz yüksek performans storage class'ları ve uzun snapshot retention maliyet yaratabilir.
Benzer şekilde her Service için ayrı public load balancer açmak bazı platformlarda ek maliyet oluşturabilir. Ingress veya Gateway ile ortak giriş katmanı değerlendirilebilir; ancak güvenlik ve izolasyon gereksinimleri korunmalıdır.
Network tarafında ise şu akışları takip edin:
- cross-zone traffic
- cross-region traffic
- internet egress
- NAT
- load balancer data processing
- dış database veya başka cloud'a trafik
Kubernetes cost raporu yalnız compute içermemelidir.
Logging ve observability maliyeti kontrol edilmelidir
Container ortamında log hacmi hızlı büyüyebilir.
Özellikle:
- debug log
- yüksek cardinality metric
- gereğinden uzun retention
- tekrar eden error log
- tüm logların aynı pahalı storage tier'ında tutulması
maliyeti artırabilir.
Ama maliyet gerekçesiyle kritik security ve incident loglarını kapatmak doğru değildir.
Namespace ve workload bazlı maliyet görünürlüğü kurun
Paylaşımlı cluster'da toplam node faturası yeterli değildir.
Maliyeti mümkünse şu seviyelerde ayırın:
- namespace
- team
- application
- environment
- workload
- label
- cost center
Böylece en pahalı ekip, boş capacity rezerve eden namespace ve sürekli düşük utilization gösteren workload görünür hale gelir.
Development cluster'ları production gibi çalışmak zorunda değildir
Production cluster yüksek availability gerektirebilir. Development ve test ortamlarında ise:
- node sayısı azaltılabilir
- mesai dışı scale-down uygulanabilir
- daha küçük node kullanılabilir
- ephemeral environment tercih edilebilir
Ama staging'in production davranışını doğrulaması gerekiyorsa minimum topoloji gereksinimleri korunmalıdır.
Spot kapasite nerede kullanılabilir?
Spot veya interruptible node'lar şu workload'larda değerlendirilebilir:
- batch
- CI runner
- stateless worker
- yeniden başlatılabilen job
- fault-tolerant processing
Tek replica stateful workload veya interruption toleransı düşük servislerde default tercih olmamalıdır.
Spot kullanımında PodDisruptionBudget, topology, fallback node group ve interruption handling tasarlanmalıdır.
Kubernetes cost optimization için önerilen sıra
1. Maliyeti görünür yapın
Node, namespace, workload ve storage bazında maliyeti ayırın.
2. Request-gerçek kullanım farkını bulun
Sürekli yüksek request / düşük usage gösteren workload'ları belirleyin.
3. Rightsizing yapın
CPU ve memory request'lerini workload davranışına göre güncelleyin.
4. Workload autoscaling'i kontrol edin
HPA/VPA ayarlarının application davranışıyla uyumlu olduğundan emin olun.
5. Node autoscaling'i optimize edin
Minimum node, instance family, scheduling constraint ve consolidation davranışını inceleyin.
6. Storage ve network israfını temizleyin
Unused volume, gereksiz load balancer ve egress pattern'lerini kontrol edin.
7. Pricing modelini değerlendirin
Stabil baseline için commitment, fault-tolerant workload için spot gibi modelleri doğru kapasite belirlendikten sonra değerlendirin.
Önce pricing indirimi satın alıp sonra rightsizing yapmak yanlış kapasiteye taahhüt verme riskini artırabilir.
Sık yapılan hatalar
Tüm request'leri toplu düşürmek: Workload davranışı ölçülmeden yapılan değişiklik production riskidir.
Node utilization'a tek metrikten bakmak: CPU düşük olsa bile memory veya scheduling constraint node'u dolu tutabilir.
Autoscaler varsa cluster otomatik ucuzlar sanmak: Yanlış request ve minimum değerler autoscaler'ın hareket alanını sınırlar.
Spot'u tüm workload'lara uygulamak: Availability riski yaratabilir.
Monitoring'i kapatmak: Görünürlük kaybı cost optimization'ı imkânsız hale getirir.
Yalnız node fiyatını takip etmek: Storage, network, logging ve operasyon maliyeti görünmez kalır.
Dynamis'te Kubernetes maliyet değerlendirmesi
Dynamis'te Kubernetes cost review şu verilerle başlar:
- node inventory
- node utilization
- Pod CPU/memory request
- gerçek workload kullanımı
- HPA/VPA davranışı
- node autoscaling
- storage
- load balancer
- data transfer
- observability
- environment ayrımı
Ardından rightsizing, node consolidation, autoscaling tuning, storage cleanup, network optimization ve pricing model review aksiyonları belirlenir.
Kubernetes platformunun operasyon ve kapasite modelini birlikte değerlendirmek için DevOps ve Kubernetes hizmetini inceleyebilirsiniz.
Cloud maliyet görünürlüğü için FinOps hizmetini ayrıca değerlendirebilirsiniz.
Sırada ne var
- Kubernetes nedir?
- Kubernetes'e geçiş rehberi
- Kubernetes production sorunları
- Cloud Rightsizing Nedir?
- DevOps ve Kubernetes hizmeti
- FinOps hizmeti
Kaynaklar
Kaynaklar
- 1.Resource Management for Pods and ContainersKubernetes · 2026-10-12
- 2.Horizontal Pod AutoscalingKubernetes · 2026-10-12
- 3.Vertical Pod AutoscalingKubernetes · 2026-10-12
- 4.Node AutoscalingKubernetes · 2026-10-12
Sık sorulan sorular
Kubernetes maliyeti nasıl hesaplanır?
Kubernetes maliyeti control plane veya managed service ücreti dışında worker node compute, persistent storage, load balancer, network/data transfer, logging/monitoring ve destek/operasyon maliyetlerinden oluşur. En büyük kalem çoğu cluster'da node kapasitesidir.
Resource request ve limit ayarları Kubernetes maliyetini etkiler mi?
Evet. Scheduler Pod yerleşimini resource request değerlerine göre yapar. Gereğinden yüksek request değerleri node kapasitesinin boş kalmasına ve daha fazla node ihtiyacına yol açabilir; çok düşük değerler ise performans ve stabilite riski yaratabilir.
Node autoscaling Kubernetes maliyetini düşürür mü?
Doğru yapılandırıldığında node autoscaling kullanılmayan node kapasitesini konsolide ederek maliyeti azaltabilir. Ancak Pod request'leri, scheduling constraint'leri ve minimum node sınırları hatalıysa beklenen tasarruf oluşmayabilir.
Kubernetes cluster'ında idle kaynak nasıl bulunur?
Pod request değerleri ile gerçek CPU/memory kullanımı, node allocatable kapasitesi, boşta kalan node'lar ve sürekli düşük utilization gösteren workload'lar birlikte incelenir. Uzun dönemli metrik olmadan yalnız anlık kullanım üzerinden rightsizing yapılmamalıdır.
Kubernetes maliyet optimizasyonuna nereden başlanmalı?
Önce workload ve node maliyetini görünür hale getirin; ardından resource request'leri, idle node'ları, autoscaling davranışını, storage ve data transfer kalemlerini inceleyin. İndirim veya spot kapasite kararları rightsizing sonrasında değerlendirilmelidir.