Kubernetes'te HPA, VPA ve Cluster Autoscaler: Birlikte Doğru Kullanım

Kubernetes'te ölçekleme konuşulunca genelde tek bir araç öne çıkarılır.
Gerçekte ise üç katman birlikte çalışır:

• HPA: Pod sayısını artırır/azaltır
• VPA: Pod resource request/limit değerlerini optimize eder
• Cluster Autoscaler: Node sayısını artırır/azaltır

Bu üçlü doğru tasarlanmazsa sistem ya pahalı olur ya da yük altında kırılır.

---

1) Ne, neyi ölçekler?

HPA (Horizontal Pod Autoscaler)

• Sinyal: CPU, memory veya custom metric
• Aksiyon: Replica sayısını değiştirir
• Güçlü olduğu yer: değişken trafik

VPA (Vertical Pod Autoscaler)

• Sinyal: Geçmiş kullanım trendi
• Aksiyon: Pod resource request/limit önerir veya uygular
• Güçlü olduğu yer: stabil ama yanlış boyutlanmış servisler

Cluster Autoscaler

• Sinyal: Schedulable olmayan podlar / boş node'lar
• Aksiyon: Node ekler veya kaldırır
• Güçlü olduğu yer: altyapı kapasite yönetimi

---

2) En kritik kural: HPA + VPA aynı hedefte kör çalışmasın

Aynı deployment üzerinde hem HPA'nın CPU'ya göre ölçekleyip hem de VPA'nın CPU request'i sürekli değiştirmesi geri besleme döngüsü yaratır.

Pratik çözüm:

• CPU/memory tabanlı HPA kullandığınız workload'larda VPA'yı recommendation mode'da tutun.
• VPA'nın auto mode'unu daha çok batch/cron workload'larda tercih edin.

Bu yaklaşım "çakışan kontrol döngülerini" azaltır.

---

3) Doğru metrik seçimi

Sadece CPU metriklerine bakmak çoğu API için yetersizdir.

Önerilen öncelik:

1. İş etkisi metrikleri (queue length, request latency, in-flight jobs)
2. Sistem metrikleri (CPU, memory)
3. Koruma metrikleri (error rate, saturation)

Örnek:

• Worker servisinde HPA metriği: queue_depth
• API servisinde HPA metriği: requests_per_second + p95_latency

Böylece ölçekleme, teknik değil iş yükü merkezli olur.

---

4) Stabilite için cooldown ve davranış pencereleri

HPA'da varsayılan davranışlar agresif kalabilir.
Production'da genelde scale down'ı daha yavaş tutmak daha güvenlidir.

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
      - type: Percent
        value: 100
        periodSeconds: 60
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
      - type: Percent
        value: 20
        periodSeconds: 60

Bu ayar ani yükselişlerde hızlı tepki, düşüşte kontrollü geri çekilme sağlar.

---

5) Cluster Autoscaler tarafında sık yapılan hatalar

• Node pool'lar arası kapasite farkını hesaba katmamak
• Çok düşük node sayısıyla başlayıp scale-up süresini küçümsemek
• Pod anti-affinity ve PDB kurallarının kapasite etkisini göz ardı etmek

İyi pratik:

• Kritik servisler için minimum güvenli node tabanı bırakın
• Spot/preemptible node kullanıyorsanız fallback on-demand havuzu tanımlayın
• Pending pod alarmlarını autoscaler loglarıyla birlikte izleyin

---

6) Maliyet ve dayanıklılık dengesini kurmak

Autoscaling sadece "yükte ayakta kalma" için değildir; doğru kurguda maliyet optimizasyonu da sağlar.

Örnek strateji:

• Gündüz yüksek trafik saatlerinde HPA üst sınırı geniş
• Gece scale-down penceresi daha agresif
• Haftalık VPA önerileri gözden geçirilip elle uygulanır

Bu model ekipte kontrol duygusunu korurken otomasyonun faydasını da aldırır.

---

7) Uygulama planı (30 günlük)

1. Hafta 1: HPA metriklerini iş metrikleriyle yeniden tanımla
2. Hafta 2: HPA behavior ve alarm eşiklerini kalibre et
3. Hafta 3: VPA'yı recommendation mode'da aç, rapor topla
4. Hafta 4: Cluster Autoscaler node pool stratejisini optimize et

Bu sırayla ilerlemek, aynı anda çok fazla değişiklikten doğacak riskleri azaltır.

---

Sonuç

Kubernetes autoscaling tek bir düğme değil, üç katmanlı bir kontrol sistemidir.
HPA, VPA ve Cluster Autoscaler birlikte doğru konumlandığında:

• Trafik dalgalarında daha az kesinti yaşanır,
• Kaynak kullanımı daha verimli olur,
• SRE ekibinin operasyon yükü azalır.

Temel hedef, "maksimum otomasyon" değil; öngörülebilir davranan bir otomasyon olmalıdır.