KUBERNETES AUTOSCALING HPA VE VPA

Pod sayısını mı artırmalı, yoksa mevcut pod'lara daha fazla CPU ve bellek mi vermeli? Kubernetes üzerinde trafik dalgalanmalarıyla karşılaşan herkesin er ya da geç verdiği bir karar bu. HPA tarafına yönelirseniz yatay büyürsünüz, VPA tarafına yönelirseniz dikey. Yanlış seçim ya kaynak israfına ya da gece yarısı patlayan alarma çıkar — ve ikisini aynı metrik üzerinde aynı anda çalıştırmak işleri büsbütün karıştırır.

1. HPA ve VPA Aynı Şeyi Yapmaz

Horizontal Pod Autoscaler (HPA), bir Deployment veya StatefulSet'in replika sayısını CPU, bellek ya da özel metriklere göre ayarlar. Yük arttığında pod sayısı çoğalır, azaldığında küçülür. Vertical Pod Autoscaler (VPA) ise replika sayısına dokunmaz; pod'ların resources.requests ve resources.limits değerlerini geçmiş kullanıma bakarak yeniden hesaplar.

Yani HPA "kaç tane?" sorusunu, VPA "ne kadar büyük?" sorusunu yanıtlar. Bu ayrımı netleştirmeden seçim yapmak, çoğu otoskalama tartışmasının çıkış noktasıdır.

• HPA: Replika sayısını ölçekler, anlık tepki verir, stateless servisler için biçilmiş kaftan.
• VPA: Pod boyutunu ayarlar, uzun vadeli kullanım verisiyle çalışır, stateful veya tek-replikalı iş yüklerinde değerlidir.
• Cluster Autoscaler: İkisinden de farklı — node sayısını yönetir, ama HPA/VPA'nın taleplerine zemin hazırlar.

2. Hangi Senaryoda HPA Mantıklıdır?

HPA, paralelleşebilen ve durumsuz iş yüklerinde parlar. Bir REST API düşünün: istek geldikçe yeni pod ayağa kalkar, yük geçince geri çekilir. Aynı şey worker'lar, web sunucuları ve mesaj kuyruğu tüketicileri için geçerlidir. Kubernetes eğitimi sürecinde sıkça karşılaşılan ilk gerçek autoscaling örneği genelde budur.

HPA'nın güçlü olduğu noktalar:

1. Trafik ani sıçradığında saniyeler içinde yeni pod açar.
2. Pod restart'a gerek kalmaz; mevcut pod'lar dokunulmadan kalır.
3. Custom Metrics API ile RPS, kuyruk derinliği, gecikme gibi iş metriklerine bağlanabilir.

Ancak iş yükü tek bir uzun bağlantıya, büyük bir in-memory cache'e veya paralelleştirilemeyen bir hesaplamaya dayanıyorsa HPA çare olmaz. Yeni replika açmak işi bölmez — sadece kaynak yer. Davranışın algoritmik detayları, eşik hesaplama formülleri ve tolerance gibi ince ayarlar için resmi dokümantasyonu incelemek doğru başlangıç noktasıdır.

3. VPA Hangi Durumda Doğru Tercihtir?

VPA, yatay ölçeklenmesi zor iş yüklerinde devreye girer. Tek bir Redis master, bir Kafka broker, bir PostgreSQL primary, ya da JVM tabanlı bir uygulamanın bellek davranışı bunlara örnektir. Bu tür servislerde replika eklemek karmaşıklığı artırır; doğrusu pod'un boyutunu işin gerçek talebine yaklaştırmaktır.

VPA üç modda çalışır:

• Off: Sadece öneri üretir, hiçbir şeye dokunmaz — kapasite planlaması için ideal.
• Initial: Yalnızca pod ilk yaratıldığında requests değerlerini günceller.
• Auto / Recreate: Çalışan pod'u evict edip yeni boyutla yeniden başlatır.

Auto modu güçlüdür ama bedeli vardır: VPA, requests değişikliği için pod'u öldürür. Disruption Budget'ı doğru kurmadıysanız tek-replikalı bir veritabanı VPA tarafından kesintiye uğratılabilir.

4. Aynı Anda HPA ve VPA: Görünmez Tuzak

En kritik noktaya geldik. HPA ve VPA'yı aynı Deployment üzerinde, aynı kaynak metriğiyle (CPU veya bellek) çalıştırırsanız çakışırlar. Senaryo şudur: HPA, CPU kullanımı %70'i geçince yeni replika açmaya karar verir. VPA ise aynı CPU verisini görüp pod'un requests değerini büyütür. Sonuç: HPA için %70'in altına düştüğü görünür, replika sayısı azalır; ardından yük tekrar yoğunlaşır ve döngü titrek bir şekilde salınır.

Resmi öneri net: HPA ve VPA'yı aynı kaynak metriği üzerinde aynı anda auto modda kullanmayın. Güvenli kombinasyonlar şunlardır:

1. HPA'yı custom metric (örneğin RPS, kuyruk boyu) üzerinde çalıştırın, VPA'ya CPU/bellek requests'i bırakın.
2. VPA'yı yalnızca recommendation modunda tutun, sayıyı HPA yönetsin, boyut önerisini insan onaylasın.
3. Aynı kaynak metriği için tek bir scaler seçin — ikisini birden değil.

5. Metrik Seçimi: Çoğu Hata Buradan Başlar

CPU kullanımı kolay ölçülür ama her zaman doğru sinyal değildir. Bellek bağımlı bir uygulamada CPU'yu izlemek yanıltıcıdır; I/O bağımlı bir servis ise hiçbir kaynak metriği üzerinden anlamlı ölçeklenmez. Bu noktada Prometheus Adapter veya KEDA gibi araçlar devreye girer: HPA, RPS, kuyruk derinliği, gecikme yüzdelikleri gibi iş katmanı metriklerine bağlanabilir.

Pratik bir checklist:

• İş yükü gerçekten neyle sınırlı? CPU mu, bellek mi, gecikme mi, kuyruk mu?
• Pod'un soğuk başlangıç süresi ne kadar? 60 saniyeyse ani trafiğe HPA yetişmeyebilir.
• Minimum ve maksimum replika sınırı gerçekçi mi? Üst sınırın bütçe etkisini hesapladınız mı?
• Stabilization window doğru ayarlandı mı? Aksi halde scaler her dalgada zıplar.

6. Cluster Autoscaler ile İlişki

HPA daha fazla pod ister, ama node'larda yer kalmamışsa pod Pending durumunda kalır. Burada Cluster Autoscaler (veya Karpenter) devreye girip node ekler. Yani üç katmanlı bir hiyerarşi vardır: VPA pod'un içini, HPA pod sayısını, Cluster Autoscaler node sayısını yönetir. Üçünü uyumlu kurmadan otoskalama hikâyesi yarım kalır.

Tipik bir hata, HPA'nın üst sınırını cluster kapasitesinden bağımsız belirlemektir. Replika hedefi 50, ama node havuzu ancak 30'a yeter — gerisi Pending kalır ve alarm üretir. Maksimum sınır, cluster kapasitesi ve bütçe ile birlikte düşünülmelidir.

7. Üretimde Çalışan Bir Düzen Kurmak

Çoğu ekip üretimde şu kalıba yakınsar: Stateless servisler için custom metric tabanlı HPA, stateful veya tek-replikalı servisler için VPA (genellikle recommendation modunda), arka planda Cluster Autoscaler. Kubernetes konularını derinleştirmek için kubernetes eğitimi içeriklerinden yararlanabilir, autoscaling mimarisini lab ortamında deneyerek pekiştirebilirsiniz.

Son olarak gözlemlenebilirlik şart. Metric server, Prometheus, scaler eventleri ve pod restart sayısı izlenmeden hangi scaler'ın ne zaman tetiklendiği anlaşılmaz. Otoskalama, "kur ve unut" işi değildir — yük profili değiştikçe eşikler de yeniden kalibre edilir.