Giriş
Kubernetes üzerinde çalışan uygulamalarınızın trafiğe göre otomatik ölçeklenmesi, maliyet ve performans dengesini korumak için kritik öneme sahiptir. Horizontal Pod Autoscaler (HPA), pod sayısını metriklere göre dinamik olarak artırıp azaltarak bu dengeyi sağlar. Bu rehberde, Kubernetes’te HPA’yı adım adım nasıl kuracağınızı, doğru metrikleri nasıl seçeceğinizi ve üretim ortamlarında dikkat edilmesi gereken noktaları paylaşacağım.
Neden HPA?
HPA, belirli bir hedefe (örneğin CPU kullanımının %70’te kalması) göre pod sayısını yatayda (horizontal) değiştirir. Ani trafik artışlarında hızlıca ölçeklenmek, düşük trafik saatlerinde ise maliyeti kısmak için idealdir. Üstelik Kubernetes 1.26+ sürümlerinde autoscaling/v2 API’si ile birden fazla metriği aynı anda değerlendirerek daha akıllı kararlar verebilir.
Önkoşullar
HPA’nın doğru çalışması için kümenizde bazı bileşenlerin hazır olması gerekir. En kritik bağımlılık metrics-server’dır. Bu bileşen, CPU ve bellek gibi kaynak metriklerini Kubernetes API üzerinden ulaşılabilir kılar.
Ayrıca Deployment’ınızdaki container’ların resource requests/limits alanlarının tanımlı olması gerekir. Aksi hâlde HPA CPU/Bellek bazlı hedefleri doğru hesaplayamaz.
Metrics Server Kurulumu (Örnek)
Çoğu yönetilen Kubernetes hizmeti (GKE, AKS, EKS) metrics-server’ı hazır getirir. Kendi kümenizde kurmanız gerekiyorsa, resmi manifest veya Helm chart kullanabilirsiniz.
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
kubectl get apiservices | grep metrics
kubectl top nodes
kubectl top pods -A
Yukarıdaki komutlar hatasız çalışıyorsa, metrik akışı sağlanmıştır ve HPA için hazırsınız.
Örnek Uygulama ve HPA Tanımı
Aşağıdaki örnekte CPU hedefi %70 olan bir HPA tanımı bulunuyor. API sürümü olarak autoscaling/v2 kullanıyoruz. Bu sürüm, ölçeklendirme davranışını (behavior) detaylı kontrol etmeye izin verir.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-api-hpa
namespace: default
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: web-api
minReplicas: 2
maxReplicas: 15
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
behavior:
scaleUp:
stabilizationWindowSeconds: 30
policies:
- type: Percent
value: 100
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 20
periodSeconds: 60
selectPolicy: Min
Bu yapılandırma, ihtiyaç durumunda pod sayısını hızlı artırırken (burst trafiği yakalama), azaltma işlemlerinde daha konservatif davranır (ani düşüşlerde dalgalanmayı engelleme).
Gelişmiş Metrikler: CPU, Bellek, Özel ve Harici
HPA, birden fazla metrikle çalışabilir ve ölçeklendirme kararını en baskın sinyale göre verir:
CPU/Bellek (Resource): averageUtilization ile yüzdesel hedefler verilir. CPU için genellikle %60–70, bellek için uygulama karakteristiğine göre %60–80 yaygındır.
Object/Pods: Uygulama seviyesinde RPS (request per second) gibi metrikleri pod başına normalize ederek ölçeklenebilir. Örneğin Nginx Ingress üzerinden istek sayısı.
External: Prometheus Adapter gibi bir adaptörle gecikme süresi, kuyruk uzunluğu, Kafka lag gibi harici metriklere göre ölçeklendirme yapılabilir.
Test: Yük Üreterek Doğrulama
HPA’nın doğru tepki verip vermediğini anlamak için kısa süreli bir yük testi yapabilirsiniz. Örneğin hey veya k6 ile endpoint’lerinize istek gönderebilir, ardından aşağıdaki komutla HPA durumunu izleyebilirsiniz:
kubectl describe hpa web-api-hpa
kubectl get hpa
kubectl top pods -n default
Çıkışta “Current” ve “Target” metrikleri ile “Desired Replicas” alanının beklenen şekilde değiştiğini gözlemlemelisiniz.
En İyi Pratikler
1) Doğru resource requests/limits: “request” değerlerini gerçekçi belirleyin. Çok düşük değerler HPA’yı gereğinden fazla tetikler; çok yüksek değerler ise ölçeklenmeyi geciktirir.
2) Stabilizasyon pencereleri: behavior.scaleDown altında 300–600 saniye aralığı çoğu web uygulaması için uygundur. Bu, titremeyi (flapping) azaltır.
3) Çoklu metrik kullanın: CPU’ya ek olarak RPS veya kuyruk uzunluğu gibi iş metrikleri eklemek daha doğru ölçeklendirme sağlar. Baskın metrik prensibini unutmayın: en yüksek gereksinimi işaret eden metrik kazanır.
4) Soğuk başlangıç sürelerini hesaba katın: Container başlatma süresi uzunsa scaleUp politikalarını daha agresif yapın; ör. Percent 100 veya Pods 4 gibi.
5) Pod Disruption Budget (PDB) ve Readiness: HPA ile birlikte PDB ve readinessProbe ayarlarını gözden geçirerek ölçeklenme ve dağıtım sırasında kesinti riskini azaltın.
6) VPA ve HPA birlikte kullanım: HPA yatay, VPA dikey ölçekleme yapar. Aynı kaynağı aynı anda hedeflememek için VPA’yı “recommendation” modunda çalıştırmayı değerlendirin.
Sık Karşılaşılan Hatalar ve Çözümler
Hata: HPA metrik okuyamıyor. Çözüm: metrics-server’ın sağlıklı çalıştığını doğrulayın; API erişim hatalarını ve TLS ayarlarını kontrol edin.
Hata: Pod sayısı artmıyor. Çözüm: Deployment’ın replicas alanı başka bir kontrolcü tarafından sabitlenmiş olabilir. Ayrıca node kapasitesi yetersizse Cluster Autoscaler gerekebilir.
Hata: Ölçeklendirme çok agresif veya çok yavaş. Çözüm: behavior.policies ve stabilizationWindowSeconds değerlerini gözden geçirin; metrik hedeflerini (averageUtilization) gerçek yük profiline göre ayarlayın.
Sonuç
Doğru yapılandırılmış bir HPA, Kubernetes ortamınızda esneklik ve maliyet verimliliği sağlar. Metrics-server, isabetli resource ayarları ve davranış politikaları ile desteklendiğinde, yük dalgalanmalarına hızla uyum sağlayan, istikrarlı ve performanslı bir mimari kurabilirsiniz. Üretime geçmeden önce küçük bir yük testiyle ayarları doğrulamak, canlıya çıktıktan sonra ise metrikleri izleyip ince ayar yapmak en sağlıklı yaklaşımdır.
