Tuhaf ama, Bulutta autoscaling denince çoğu kişinin aklına tek şey geliyor: trafik artınca büyü, düşünce küçül, faturayı da usulca aşağı çek (ciddiyim). Kağıt üstünde mantık tam bu. Ama işin aslı şu ki, yanlış ayarlanmış bir autoscaling sistemi bazen tam tersine çalışıyor — ay sonunda size küçük bir sürpriz değil, bayağı sert bir fatura bırakıyor.
Geçen sene Eylül ayında, İstanbul’daki bir SaaS ekibiyle yaptığım görüşmede tam buna benzer bir tablo gördüm (şaşırtıcı ama gerçek). HPA açık, node’lar Cluster Autoscaler ile gayet — ki bu tartışılır — neşeli şekilde büyüyor… ama aylık maliyet beklenenin çok üstüne çıkmış. “Trafik arttı herhalde” dediler önce. Meğer trafik değil, ölçekleme politikası kendi kendini kovalıyormuş (yanlış duymadınız). Hani araba park hâlinde ama motor boşta bağırıyor ya — işte aynen öyle.
Bunu biraz açayım.
Tuhaf ama, Bir de şu var. Autoscaling kötü bir fikir değil (yanlış duymadınız). Hatta doğru kurulduğunda gerçekten çok işe yarıyor, bunu teslim etmek lazım. Sorun genelde araçta değil; ayarda, eşikte, kaynak isteğinde ve o meşhur “default bırak gitsin” yaklaşımında çıkıyor. Gel gelelim, bulut faturası da biraz acımasızdır; yanlış kararları pek affetmiyor.
Autoscaling Neden Bazen İşe Yaramaz?
Bunu yaşayan biri olarak söyleyeyim, Autoscaling’in temel vaadi basit: yalnızca kullandığın kadar öde (bu beni çok şaşırttı). Ama Kubernetes dünyasında bu cümle tek başına yetmiyor. Çünkü sistem yalnızca trafiğe bakmıyor; pod request değerlerine, limitlere, ortalamalara. Anlık dalgalanmalara da bakıyor — yani aslında mesele “kaç istek geldi?” sorusundan çok daha karışık bir hâl alıyor.
Ben 2024’ün başında Ankara’da bir ekipte test ortamını incelerken şunu fark ettim: uygulama neredeyse hiç yük almıyordu. HPA sürekli tetikleniyordu. İlk bakışta saçma geldi açıkçası (ki bu çoğu kişinin gözünden kaçıyor). Sonra CPU request değeri ile gerçek idle kullanımının birbirini tutmadığını gördük (kendi tecrübem). Küçük gibi duran bu fark, birkaç gün içinde gereksiz replica üretimine dönüşmüştü. Kimse fark etmemişti.
Autoscaling iyi kurulursa rahatlatır; kötü kurulursa sessizce para yakar. En tehlikeli tarafı da budur zaten: sistem çalışıyordur, hata vermez, ama bütçe kan kaybeder.
Bilmem anlatabiliyor muyum, Şimdi burada klasik “sadece CPU’ya bakmak yeterli mi?” sorusu çıkıyor ortaya. Kısa cevap: hayır. CPU anlık dalgalanır, pod’lar başlarken zıplar, kısa süreli spike’lar metrikleri şaşırtır… ve controller bunu gerçek talep sanabilir. Çoğu zaman da sanıyor zaten.
HPA’nın Mantığı Sandığınızdan Daha İnce
CPU usage değil, CPU request önemli
İnsanların en çok kaçırdığı nokta bu oluyor. HPA genelde raw CPU kullanımına bakmıyor; pod’un CPU request değerine göre hesap yapıyor. Yani siz pod’a 100m request verip limitini 2000m yaparsanız. Uygulama boşta bile 60m civarı geziyorsa — sistem bunu hafif hafif “yük var” diye okuyabiliyor. Ve okuyunca da harekete geçiyor tabii.
İnanın, Bunu mutfak örneğiyle anlatayım. Masada iki tabak var diye aç olduğunuzu düşünmek gibi bir şey bu — tabak sayısı başka şeydir, gerçekten ne kadar yediğiniz bambaşka bir şeydir. HPA da benzer şekilde bazen görüntüye bakıp yorum yapıyor, gerçeğe değil. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Sürekli yeniden hesaplanan bir denklem
Şöyle ki, Kullanılan formül kaba hâliyle şöyle işler:
desiredReplicas = ceil(currentReplicas * (currentUtilization / targetUtilization))Eğer currentUtilization zaten hedefin üzerindeyse sistem her döngüde biraz daha büyür. Küçük startup ortamlarında bu bazen komik görünür; iki pod’dan üçe çıkar, sonra dörde… Kurumsal tarafta işe işin rengi tamamen değişir, çünkü node sayısı da oynar, storage da etkilenir, network de kıpırdar. Zincirleme gider yani. Apple’ın Akıllı Gözlüğü: Neden Asıl Sürpriz O Olabilir? yazımızda bu konuya da değinmiştik.
| Durum | Ne ölür? | Maliyet etkisi |
|---|---|---|
| Düşük CPU request | HPA pod’u hep yoğun sanır | Replica sayısı artar |
| Aşırı yüksek limit | Pod’a geniş nefes alanı verilir ama kontrol zorlaşır | Kapasite boşa gider |
| Dengesiz target değeri | Sistem sürekli ileri geri zıplar | Bütçe şişer |
Açık konuşayım: HPA’yı yanlış yorumlamak çok kolay. Grafikte güzel görünür; çizgi yukarı çıktığında replika artar… sanki her şey sağlıklıymış gibi durur. Oysa perde arkasında sadece fazla hareket vardır. Fazla hareket, fazla para demek.
Kısa bir not düşeyim buraya. Azure Firewall Premium: TLS Açmadan Para Yakıyor müsünüz? yazımızda bu konuya da değinmiştik. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Büyük Faturaya Giden Dört Klasik Yol
1) Target değeri idle seviyesinin altında kalınca
Eğer targetCPUUtilizationPercentage değeri gerçek idle kullanımından düşükse HPA resmen boşta bile alarm verir. Mesela uygulamanız normalde 60m kullanıyorsa ve target’ı 50’ye çektiyseniz sistem bunun altından kalkamaz; sürekli yeni replica ister. Durdurmak da kolay değildir bir kez başlayınca.
Bunu ilk kez İzmir’de bir e-ticaret projesinde gördüm. Saat gece üçte bile servis ölçekleniyordu. Trafik yoktu. Cluster hareketliydi. Meğer ürün ekibinden biri “güvenli olsun” diye target’ları fazla agresif ayarlamıştı — iyi niyetle yapılmış,. Sonucu pek iç açıcı değildi.
2) HPA ile VPA aynı anda auto modda çalışınca
Bu ikili bazen birbirini dürtüp duruyor. VPA pod’u evict ediyor, yeni pod ayağa kalkarken kısa spike oluşuyor, HPA bunu yük sanıp replica ekliyor… sonra VPA tekrar öneri üretiyor ve oyun yeniden başlıyor. Güzel bir kısır döngü değil mi? Değil tabii.
Küçük ekiplerde bu döngü genelde loglardan anlaşılır. Kurumsalda işe olay sessizce büyür çünkü farklı namespace’lerde farklı davranışlar görürsünüz ve herkes topu başka yere atar. Sonunda kimse sahip çıkmaz soruna. Daha fazla bilgi için ABD Senatosu’nda Kripto Haftası: Clarity Act ve Bankalar Gündemde yazımıza bakabilirsiniz.
3) Cluster Autoscaler her spike’ta node açarsa
Şahsen, Sadece pod sayısı değil node sayısı da büyüyorsa maliyet iki kat can sıkıcı hâle gelir. Bilhassa de kısa süreli pikler için yeni node açıp sonra onları boşta bekletmek pek akıllıca değildir. Teknik olarak çalışır, evet. Ekonomik olarak işe pek parlak değildir (yanlış duymadınız)
Neyse uzatmayalım: autoscaler’ın tepki süresi ile iş yükünüzün doğası uyumlu olmalı. Anı yükselen ama çabuk sönen trafikte agresif node ölçekleme çoğu zaman fazla heyecanlı davranmak demek oluyor. Sistem panikliyor ama aslında panikleyecek bir şey yok.
4) Yanlış ölçülen metrikler yüzünden zincirleme hata oluşunca
Metrik kaynağı eksikse veya gecikmeli geliyorsa controller gerçek zamanı kaçırabilir. Bu durumda siz dashboard’da sakın bir çizgi görürsünüz ama sistem içeride panik yapıyordur — evet, biraz sınır bozucu. İşin kötüsü bu tür hatalar genelde en son fark ediliyor.
Bütçeyi Kurtarmanın Pratik Yolları
Lafı gevelemeden söyleyeyim: çözüm “autoscaling’i kapat” değil. Hiç değil. Çözüm önü göz kararıyla kurmayı bırakmak. Önce birkaç günlük gerçek idle tüketimini ölçün; sonra CPU request’i buna yakın konumlandırın. Bunun üstüne target değerini körlemesine %50’ye sabitlemek yerine servisinizin gerçek davranışına göre belirleyin — bu kadar.
- IDLE CPU’yu ölçün: En az birkaç gün boyunca boş saatleri izleyin.
- Request’i abartmayın: Çok yüksek request = yaniltıcı güven hissi.
- VPA’yı dikkatli kullanın: Auto yerine önce Recommend mode deneyin. (bu kritik)
- Kısa spike’ları filtreleyin: Her küçük sıçrama için scale-out istemeyin.
- Metrikleri çapraz kontrol edin: Sadece CPU’ya yaslanmayın; latency ve queue depth’e de bakın.
Editör masasında bu yazıyı hazırlarken kendi test notlarıma baktım — Şubat ayında kurduğum minik bir demo kümesinde sırf düşük request yüzünden iki replika beşe çıkmıştı. Üstelik uygulama neredeyse hiçbir iş yapmıyordu! İnsan önce kodu suçluyor tabii. Halbuki suçlu çoğu zaman YAML dosyasındaki o küçük rakam oluyor. Hep öyle oluyor zaten.
Küçük Startup ile Enterprise Arasındaki Fark Ne?
Küçük startup tarafında sorun genelde gözden kaçıyor. Trafik az olabiliyor ve birkaç dolarlık oynama kimsenin radarına girmiyor gibi görünüyor. Ama ay sonu geldiğinde o ufak sapmalar birleşip can sıkıcı bir yekun oluşturuyor. Bilhassa de paylaşımlı cloud hesaplarında bu daha net hissediliyor.
Büyük enterprise yapılarda işe problem finansal olmaktan çıkıp operasyonel hâle geliyor. Bir takım HPA’yı düzeltirken diğeri VPA önerilerini değiştiriyor, üçüncü ekip node pool boyutunu ellemeye başlıyor… Sonuç mu? Herkes hareket ediyor ama kimse bütçenin neden arttığını tam açıklayamıyor. Bu arada yönetim tarafından soru yağmuru başlıyor tabii.
Kime ne öneririm?
| Sahne | Tavsiye edilen yaklaşım |
|---|---|
| Küçük startup | Daha basit politika, daha az otomasyon karmaşası, düzenli manuel gözlem |
| Büyüyen ürün ekibi | SLO tabanlı metrikler, kontrollü scale-out, maliyet uyarıları |
| Enterprise | Merkezî maliyet takibi, namespace bazlı politika ayrımı, düzenli autoscaling review |
Sıkça Sorulan Sorular
Autoscaling neden bazen faturayı artırıyor?
Autoscaling “az kullanıyorsan küçül” mantığıyla çalışır ama metrikler doğru okumazsa tam tersi ölür. Örneğin CPU request/limit ayarları veya yanlış hedef değerler nedeniyle sistem “yük var” sanıp gereksiz replica üretebilir. Benim gördüğüm en yaygın senaryo, idle durumunda bile HPA’nın tetiklenmesi ve bunun günlerce fark edilmeden maliyete yansımasıydı.
HPA sadece CPU kullanımına mı bakıyor, yoksa başka şeyler de var mı?
Klasik örnekte CPU üzerinden ölçeklersiniz ama Kubernetes’te HPA’nın kararında asıl kritik nokta çoğu zaman CPU usage değil, request tabanlı hesaplamadır. CPU request ile gerçek kullanım uyuşmuyorsa (ör. request çok yüksekse) HPA sistemin durumunu yanlış yorumlayabilir. Bu yüzden “CPU’ya bakıyor” demek tek başına yeterli değil.
CPU request yanlışsa HPA nasıl gereksiz ölçekleme yapar?
CPU request değeriniz uygulamanın gerçek ihtiyacından yüksekse, sistem hedefe göre yanlış bir orana ulaşabilir ve gereksiz ölçekleme başlayabilir. Tersi durumda da (request düşükse) spike’lar sırasında sürekli büyüme görülebilir. İkisi de bütçeyi etkiler; ben test ortamlarında özellikle request/limit uyumsuzluğunun “sessiz” maliyet artırdığını çok gördüm.
Cluster Autoscaler ve HPA birlikte çalışınca neye dikkat etmek gerekir?
HPA pod sayısını artırır, Cluster Autoscaler işe node sayısını artırır. Eğer node’lar “hemen ölçecek” şekilde hazır değilse veya pod’lar sık sık binmek zorunda kalıyorsa, maliyet daha hızlı artabilir. Ayrıca yanlış node pool ayarları (instance tipi, min/max, ölçekleme sınırları) geri dönüşü zor bir döngüye yol açabilir.
Autoscaling’i doğru kurduğumu nasıl anlarım?
En iyi kontrol, sadece “replica arttı mı azaldı mı?” değil; metriklerin neden arttığını (HPA event’leri, hedef sapmaları, request/limit değerleri) takıp etmektir. Ayrıca birkaç gün boyunca maliyet trendini ve ölçekleme olaylarını birlikte incelemek, sorunu erken yakalamanızı sağlar. Ben genelde ilk adım olarak HPA hedef metriklerini ve CPU request/limit tutarlılığını netleştiriyorum.
Kaynaklar ve İleri Okuma
AKS’te Kubernetes autoscaling (HPA/Kubernetes Scale) rehberi
AKS Cluster Autoscaler dokümantasyonu
Kubernetes HPA (Horizontal Pod Autoscaler) resmî doküman
Kubernetes Autoscaler GitHub (HPA/Cluster Autoscaler kod ve dokümanlar)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
