1. GİRİŞ

Bulut‑native uygulamaların trafik ve kaynak talepleri dinamik olarak değişir. Kubernetes autoscaling mekanizmaları, uygulamaların hem maliyet verimliliği hem de kullanıcı deneyimi açısından istenen performansı korumasını sağlar. Autoscaling yalnızca kaynak eklemek veya azaltmak değildir; doğru planlandığında SLA'ların korunması, gecikmelerin azaltılması ve kaynak israfının önlenmesi için kritik bir katmandır.

Neden bugün önemli?

• Bulut maliyetlerini optimize etme ihtiyacı: Dinamik ölçekleme ile kaynaklar talebe göre tüketilir.
• Değişken trafik profilleri: Peak dönemler, kampanyalar veya ML batch job'larının etkisiyle talep dalgalanır.
• AI/ML iş yükleri ve GPU scheduling: Kaynak yönetimi yalnızca CPU/memory değil, accelerator'ları da kapsamalıdır.

Kimler için önemli?

• Platform/DevOps mühendisleri
• SRE ekipleri — SLA yönetimi
• Backend geliştiriciler — uygulama performansı ve observability sorumluları

Hangi problemleri çözüyor?

• Manuel ölçekleme riskini ortadan kaldırma
• Kaynak yetersizliğine bağlı kesintileri azaltma
• Peak'lerde maliyet ve performans dengesini sağlama

2. KAVRAMSAL TEMELLER

2.1 Auto‑scaling türleri

• Horizontal Pod Autoscaler (HPA): Pod sayısını yatayda değiştirir (replica artışı/azaltma).
• Vertical Pod Autoscaler (VPA): Pod başına CPU/memory gibi kaynak limitlerini önerir veya uygular.
• Cluster Autoscaler (CA): Node pool seviyesinde node ekleme/çıkarma yapar (cloud autoscaling ile entegre).
• Custom Autoscalers: Kendi metriklerinize göre ölçekleme yapan çözümler (KEDA, custom controllers) ve job‑based scaling.

2.2 Temel kavramlar ve terminoloji

• Target metric: HPA veya VPA tarafından hedeflenen metrik (CPU, memory, request latency, custom metric).
• Scale up / scale down: Kaynak artırma ve azaltma eylemleri.
• Cooldown / stabilization window: Ölçeklendirme sonrası beklenen süre; flapping'i önler.
• Pods pending: Scheduler node bulamazsa pod'ların beklemesi; CA trigger'ı olabilir.

3. NASIL ÇALIŞIR? — Teknik Mimari ve Veri Akışı

3.1 Horizontal Pod Autoscaler (HPA)

HPA, Kubernetes API üzerinde çalışan kontrolördür. Belirlenen metrikleri (CPU utilization, memory veya custom metrics) periyodik olarak okur ve hedeflenen metrik değerine göre Deployment/ReplicaSet üzerinde replica sayısını ayarlar. HPA v2 beta ve sonrası custom metrics, external metrics ve object metrics desteği sunar. HPA karar süreci genel olarak şu adımları izler:

1. Metrikleri metrics‑server veya Prometheus Adapter gibi bir kaynak üzerinden okur.
2. Mevcut metrik değerlerini hedef ile karşılaştırır.
3. Gerekiyorsa yeni replica sayısını hesaplar ve scaling event'ı tetikler.

3.2 Vertical Pod Autoscaler (VPA)

VPA, pod'un resource request/limit değerleri için öneriler üretir. Üç çalışma modu vardır: Off (sadece öneri), Auto (pod yeniden oluşturulduğunda yeni kaynakları uygular) ve Initial (yeni pod'lar için default request belirler). VPA ve HPA birlikte dikkatle kullanılmalıdır; çünkü birisi yatay, diğeri ise dikey değişiklikler yapar ve çakışmalar olabilir.

3.3 Cluster Autoscaler (CA)

CA, node pool'larını izler; eğer pod'lar pending ve resource fit sebepli bekliyorsa gerekli node eklenmesini sağlar. Benzer şekilde, underutilized node'ları kaldırarak maliyet tasarrufu yapar. CA genelde cloud provider autoscaling API'ları (AWS ASG, GCP instance groups, Azure VMSS) ile entegre olur.

3.4 KEDA ve event‑driven scaling

KEDA (Kubernetes Event‑Driven Autoscaling), queue length, Kafka lag, Azure Queue gibi dış metriklere göre HPA veya scaledobject tetikler. Bu yöntem, iş queue'larına dayalı bursty iş yükleri için idealdir.

3.5 Metrik toplayıcılar ve adapterlar

HPA için metrics‑server temel CPU/memory metriklerini sağlar. Daha ileri kullanımlar için Prometheus Adapter, custom metrics API veya external metrics adapter kurulmalıdır. Adapter'ler, Prometheus veya başka telemetry kaynaklarından metrikleri Kubernetes metrics API'sine expose eder.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix tarzı trafik yönetimi

Büyük ölçekli streaming servislerinde HPA + CA kombinasyonu, sudden spike'larda ek node/proxy açarak istekleri karşılar. Canary ve circuit breaker stratejileri ile otomatik ölçeklendirme desteklenir.

4.2 Uber tipi bölgesel scaling ve locality

Bölgesel cluster'larda autoscaling, regional latency ve locality kurallarına göre optimize edilir. Autoscaler kararlarında topology ve taints/tolerations göz önünde bulundurulur.

4.3 Amazon / EKS — mixed instance ve spot kullanım örnekleri

Cluster Autoscaler ile farklı node havuzları (on‑demand, spot, GPU) yönetilir. Spot instance kullanımı maliyet avantajı sağlar ancak preemption handling ve pod disruption politikaları hazırlanmalıdır.

4.4 OpenAI ve ML iş yükleri

ML eğitim ve inference iş yükleri, GPU havuzları ve node pool lifecycle ile yakından ilişkilidir. Burst job'lar için CA tetiklenirken, GPU packing ve fragmentation minimize eden scheduler ve custom autoscaler'lar kullanılır.

4.5 Stripe — Fintech ops

Fintech uygulamalarında predictability ve cost control önemlidir. Autoscaling politikaları SLO/SLI ile eşleştirilmeli, maliyet limitleri ve reserved capacity (critical workloads için) tanımlanmalıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Otomatik kaynak yönetimi ile maliyet optimizasyonu
• Talep anında performansı koruma ve SLA'ları sağlama
• Event‑driven scaling ile bursty iş yüklerine uygun yapı

Sınırlamalar

• Yanlış metrik seçimi ile gereksiz veya yetersiz scaling
• Scale kararlarının gecikmeli olması — cold start ve provisioning latency
• HPA, VPA, CA kombinasyonlarının çakışma riskleri

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• HPA için uygun hedef metrikleri seçin: uygulama gecikmesi veya throughput metrikleri genelde daha sağlıklıdır; yalnızca CPU'ya bakmak yanıltıcı olabilir.
• Cooldown ve stabilization window ayarlarını uygulayın; hızlı up/down flapping'i önlemek için hysteresis kullanın.
• Cluster Autoscaler ile node pool stratifikasyonu yapın: on‑demand, spot, GPU gibi farklı havuzlar oluşturun ve taints/tolerations ile yönlendirin.
• VPA'yı production'da uygulamadan önce "recommendation" modunda çalıştırıp önerileri değerlendirin; otomatik mod dikkatli test gerektirir.

Performans optimizasyonu

• Pod start/ready sürelerini kısaltın: image size küçültme, init container optimizasyonu ve readiness probe tuning.
• Node provisioning latency'yi azaltmak için ön‑warmed node pool veya buffer node strategy kullanın.
• Metrics cardinality'yi sınırlayın; yüksek cardinality metrikler monitoring maliyetini artırır.

Güvenlik ve maliyet kontrolü

• Autoscaler rollerine RBAC yöntemiyle minimum izinleri verin.
• Spot instance kullanırken preemption ve fallback planları oluşturun; critical workload'lar için reserved capacity ayırın.

8. SIK YAPILAN HATALAR

• Hatalı metrik seçimi: CPU yerine request latency daha anlamlı olabilir.
• VPA ve HPA'yı testing olmadan aynı objekt üzerinde auto modda çalıştırmak.
• Cluster Autoscaler için yanlış node pool tanımları ve eksik taints/tolerations konfigürasyonu.
• Metrik adapter'ları olmadan custom metriklere dayalı scaling planlamak (ör. Prometheus Adapter eksikliği).

9. GELECEK TRENDLER

1. AI‑assisted autoscaling: Telemetry verisini öğrenen modellerle daha öngörülü scaling kararları.
2. Serverless ve KNative entegrasyonları: KNative ve serverless pattern'leri ile daha ince taneli otomatik ölçekleme.
3. Hybrid autoscaling: Edge/Cloud arası global scaling ve placement optimizasyonu.
4. eBPF tabanlı observability: Daha gerçek zamanlı resource kullanım verileri ile daha hızlı scaling.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. HPA nasıl metrik alır?

   HPA temel olarak metrics‑server'dan CPU/memory alır. Daha gelişmiş kullanım için Prometheus Adapter veya custom metrics API ile uygulama metrikleri HPA'ya sunulabilir.

2. VPA ve HPA aynı anda çalıştırılabilir mi?

   Evet ama dikkatli konfigürasyon gerekir. Genelde VPA recommendation modunda tutulur, HPA ise yatay scaling'i yönetir. Otomatik VPA uygulaması, HPA kararlarını etkileyebilir.

3. Cluster Autoscaler hangi durumlarda node ekler?

   Scheduler tarafından pod'lara uygun node bulunamadığında (unschedulable), CA ilgili node pool'a yeni node eklenmesini talep eder. Ayrıca node'larda reclaim edilebilecek pod yoksa scaling down tetiklenir.

4. KEDA ne zaman tercih edilmeli?

   Queue length, Kafka lag veya event‑driven iş yükleri için KEDA idealdir; HPA'nın per‑pod metrikleri yetersiz kaldığında KEDA kullanılabilir.

5. Spot instance kullanırken nelere dikkat etmeliyim?

   Preemption riskine göre uygulamaları kategorize edin; stateful kritik iş yüklerini on‑demand node'larda tutun, batch ve stateless işlere spot node'ları yönlendirin.

6. Provisioning latency nasıl azaltılır?

   Smaller images, local cache, pre‑warmed node pools ve init container optimizasyonu ile pod/node start sürelerini kısaltın.

7. Custom metric'leri HPA'ya nasıl bağlarım?

   Prometheus Adapter veya custom metrics API ile Prometheus'dan metrikleri Kubernetes metrics API'ye expose ederek HPA kullanabilirsiniz.

8. Scaling kararlarını nasıl gözlemlerim?

   Prometheus metrikleri (hpa_behavior, cluster_autoscaler metrics), events (kubectl describe deployment) ve audit log'lar ile scaling aktivitelerini izleyin ve runbook'lar oluşturun.

Anahtar Kavramlar

HPA

Horizontal Pod Autoscaler — pod sayısını metriklere göre değiştirir.

VPA

Vertical Pod Autoscaler — pod başına kaynak önerir veya uygular.

Cluster Autoscaler

Node seviyesinde otomatik ölçeklendirme yapar (ekleme/çıkarma).

KEDA

Event‑driven autoscaling için geniş adaptör desteği sunar.

Metrics Adapter

Prometheus gibi sistemleri Kubernetes metrics API'ye bağlayan bileşen.

Öğrenme Yol Haritası

1. 0–1 ay: HPA, metrics‑server kurulumu ve temel CPU/memory metrikleri ile uygulama.
2. 1–3 ay: Prometheus kurun, Prometheus Adapter ile custom metrikleri HPA'ya bağlayın; küçük bir uygulama için HPA davranışını test edin.
3. 3–6 ay: VPA ve Cluster Autoscaler konfigürasyonları, spot/on‑demand node pool stratejileri ve KEDA ile event‑driven scaling deneyleri yapın.
4. 6–12 ay: Production‑grade autoscaling politikaları, cost control, SLO entegrasyonu ve AI‑assisted scaling fikirleri üzerinde çalışın.