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 halinde 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 hal 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 haliyle şö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 ise 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 olur? | 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 musunuz? 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 ise 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ı hale 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 ise 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ı. Ani 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 sakin bir çizgi görürsünüz ama sistem içeride panik yapıyordur — evet, biraz sinir 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 onu 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 = yanıltı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 ise problem finansal olmaktan çıkıp operasyonel hale 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 | Merkezi maliyet takibi, namespace bazlı politika ayrımı, düzenli autoscaling review |
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.
