KUBERNETES AUTOSCALİNG: HPA/VPA MANTIĞI VE ÖLÇEKLEME TUZAKLARI

Kubernetes’te autoscaling, “yük gelince büyüt, sakinleşince küçült” kadar basit görünür; fakat işin içine metrik seçimi, kaynak talepleri (requests), limitler, gecikmeler ve kontrol döngülerinin doğası girince küçük bir ayar bile üretimde dalgalanmaya yol açabilir. HPA ve VPA, doğru kullanıldığında maliyeti düşürür ve performansı dengeler; yanlış kurgu ise thrashing (sürekli büyüyüp küçülme) ve kaynak israfı üretir.

Bu yazıda Kubernetes autoscaling yaklaşımını iki ana mekanizma üzerinden ele alacağız: HPA (Horizontal Pod Autoscaler) ve VPA (Vertical Pod Autoscaler). HPA’nın metrik tabanlı replika sayısı kararlarını, VPA’nın kaynak taleplerini nasıl önerdiğini, birlikte kullanımın nerede riskli olduğunu ve en sık düşülen ölçekleme tuzaklarını gerçekçi örneklerle inceleyeceğiz.

Amacımız “tek bir YAML ile mucize” değil; aksine sistemin karar verirken hangi sinyalleri dinlediğini, bu sinyallerin nasıl bozulduğunu ve dayanıklı bir ölçekleme stratejisinin hangi guardrail’lere ihtiyaç duyduğunu netleştirmek. Daha bütüncül bir bakış için Kubernetes Eğitimi sayfasına da göz atabilirsiniz.

Kubernetes autoscaling nedir ve neden zorlaşır?

Kubernetes autoscaling, uygulama talebi değiştikçe kapasiteyi otomatik ayarlama yaklaşımıdır. Pratikte bu; replika sayısını artırmak, pod başına CPU/RAM taleplerini güncellemek, hatta gerektiğinde node sayısını büyütmek gibi farklı katmanlarda gerçekleşir. Zorluk, bu katmanların birbirini etkilemesinden gelir: yanlış request değerleri HPA’nın gördüğü yüzdeleri değiştirir, node baskısı eviction tetikler, metrik gecikmesi yanlış zamanda ölçekleme kararına yol açar.

Ölçekleme mekanizmaları birer kontrol döngüsüdür. Kontrol döngülerinde gecikme ve geri besleme her zaman vardır. Uygulama yeni replica ile ısınana kadar trafik dengesiz dağılabilir; metrik sistemleri örnekleme aralığı yüzünden gerçek yükü geç görür; bu sırada autoscaler yeni bir karar daha verirse sistem salınıma girer.

Ölçeklemenin üç katmanı: pod, node ve uygulama

• Pod ölçekleme: HPA ile replika sayısını artırıp azaltmak.
• Kaynak boyutlandırma: VPA ile CPU/RAM requests değerlerini önerip uygulamak.
• Node ölçekleme: Cluster Autoscaler ile yeni node eklemek veya boş node’u kapatmak.

Bu katmanlar aynı anda devreye girdiğinde “neden büyüyor ama yetmiyor?” veya “neden küçülmüyor?” soruları sıklaşır. Çünkü her biri farklı sinyale bakar ve farklı gecikmelere sahiptir.

HPA mantığı: yüzdelik hedefler, metrik kaynağı ve karar anı

HPA, tipik olarak CPU ya da bellek gibi metriklere bakarak replika sayısını ayarlar. CPU için en yaygın senaryo, “hedef ortalama CPU kullanım yüzdesi” yaklaşımıdır. Buradaki kritik nokta şudur: CPU yüzdesi, pod’un requests.cpu değerine göre normalize edilir. Yani requests düşük seçildiyse aynı gerçek kullanım daha yüksek yüzdeye dönüşür; requests yüksek seçildiyse yüzde düşük görünür. Bu nedenle HPA’yı doğru okumak, requests seçimini doğru yapmayı şart koşar.

Metrics Server ve metrik gecikmesi

CPU/Memory metrikleri çoğunlukla Metrics Server üzerinden gelir. Örnekleme aralığı, metriklerin gecikmeli gelmesine sebep olabilir. Uygulama anlık pik yaptığında HPA hemen tepki vermez; birkaç döngü sonra karar verir. Eğer uygulama zaten kendi içinde kuyruklanma ile “gecikmeyi” büyütüyorsa, HPA’nın geç tepki vermesi toplam gecikmeyi katlayabilir.

Hedef metrik seçimi: CPU her zaman doğru sinyal değildir

CPU düşük ama yanıt süresi yüksek olabilir; çünkü darboğaz CPU değil I/O, DB bağlantı havuzu veya dış servis olabilir. Böyle bir durumda CPU tabanlı HPA replika artırmaz ve kullanıcı gecikmesi artar. Bu nedenle kritik servislerde custom metrics veya istek başına gecikme, kuyruk derinliği gibi uygulama metrikleri düşünülür. Ancak custom metrics ile birlikte doğruluk, örnekleme, cardinality ve maliyet yeni bir karmaşıklık katmanı ekler.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: checkout-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout
  minReplicas: 3
  maxReplicas: 30
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
      - type: Pods
        value: 4
        periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 20
        periodSeconds: 60
      selectPolicy: Min
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 65

Bu örnekte scaleDown için stabilizasyon penceresi uzun tutulur; çünkü hızlı küçülme, soğuk start ve kuyruk birikimi yüzünden “dalgalı” bir deneyim üretir. Ayrıca scaleUp politikalarında hem yüzde hem pod sayısı sınırı kullanarak ani piklerde kontrollü büyüme hedeflenir.

VPA mantığı: requests ayarı, öneri motoru ve uygulama modu

VPA, pod’ların CPU/RAM kullanımını izleyip uygun requests değerleri için öneri üretir. Burada önemli ayrım, VPA’nın “limit” değil ağırlıklı olarak “request” odaklı çalışmasıdır. VPA’nın hedefi, scheduler’ın daha doğru yerleştirme yapması ve pod’ların ihtiyaç duyduğu minimum kapasiteyi makul bir seviyede garanti altına almasıdır.

VPA modları: Off, Initial, Auto

VPA üç temel modda kullanılır: yalnızca öneri üretmek (Off), pod ilk yaratılırken requests güncellemek (Initial) ve gerektiğinde pod’u yeniden başlatarak requests’i güncellemek (Auto). Üretimde en güvenli başlangıç genellikle Off veya Initial modudur. Çünkü Auto modunda pod yeniden başlatma davranışı, özellikle stateful veya gecikmeye hassas servislerde risk yaratabilir.

Recommendation penceresi ve “tekil pik” yanılgısı

VPA önerileri geçmiş kullanım istatistiklerine dayanır. Nadiren yaşanan ama çok yüksek bir pik, önerileri yukarı çekebilir. Eğer pik bir anomaliyse, VPA “ortalama ihtiyacı” değil “en kötü ihtimali” temel alarak requests yükseltir; bu da node yoğunluğunu artırır ve maliyeti büyütür. Bu yüzden VPA’yı devreye almadan önce yük profili, p95/p99 ve piklerin kökeni analiz edilmelidir.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: checkout-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: checkout
  updatePolicy:
    updateMode: "Initial"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      controlledResources: ["cpu", "memory"]
      minAllowed:
        cpu: "200m"
        memory: "256Mi"
      maxAllowed:
        cpu: "1500m"
        memory: "2Gi"

Bu örnekte min/max guardrail’leri, VPA’nın aşırı küçük veya aşırı büyük öneriler üretmesini sınırlar. Ayrıca Initial modu ile yalnızca yeni pod’larda uygulanır; mevcut pod’lar zorla yeniden başlatılmaz.

HPA ve VPA birlikte kullanımı: uyumsuzluklar ve güvenli senaryolar

HPA ve VPA’nın birlikte çalışması teoride caziptir: HPA replika sayısını ayarlar, VPA pod boyutunu optimize eder. Ancak pratikte en büyük çakışma, HPA’nın CPU yüzdesini requests üzerinden hesaplamasıdır. VPA requests’i değiştirdikçe HPA’nın gördüğü yüzdeler değişir; bu da HPA’nın replika kararlarını “metrik değişti sanıp” dalgalandırabilir.

Çakışma örneği: requests artınca HPA küçülüyor

Diyelim ki pod gerçekten 500m CPU kullanıyor. requests 500m iken CPU utilization yaklaşık %100 görünür; HPA büyütmeye meyleder. VPA requests’i 1000m’a çıkarırsa aynı gerçek kullanım %50 görünür; HPA “yük azaldı” sanıp küçülmeye gidebilir. Bu küçülme yeni kuyruklar doğurur, CPU tekrar yükselir ve sistem salınıma girer. Bu yüzden kritik iş yüklerinde HPA+VPA kombinasyonu için net kurallar gerekir.

Güvenli yaklaşım: HPA’yı custom metrics ile sürmek

HPA’yı CPU yerine istek sayısı, kuyruk derinliği veya uygulama gecikmesi gibi metriklerle sürmek, requests değişiminin etkisini azaltır. Böylece VPA, scheduler verimliliğini artırırken HPA, gerçek iş yükü sinyaliyle replika sayısını yönetir. Yine de custom metrics tarafındaki doğruluk ve gecikme iyi tasarlanmalıdır.

Ölçekleme tuzakları: en sık görülen 10 problem

Ölçekleme tuzakları genellikle “tek bir ayar” değil, birkaç kararın üst üste binmesiyle oluşur. Aşağıdaki maddeler, sahada en sık rastlanan problem desenlerini özetler.

1) Yanlış requests/limits: HPA’yı yanıltmak

requests çok düşükse HPA sürekli yüksek yüzde görür ve gereksiz replika artırır. requests çok yüksekse HPA düşük yüzde görür, büyümez ve gecikme artar. limits çok düşükse CPU throttling başlar; metrikler “kullanım” gösterse bile uygulama yavaşlar. Burada requests performans için taban, limits ise komşu izolasyonu için tavan olarak düşünülmelidir.

2) Scale-down agresifliği ve soğuk başlangıç maliyeti

Hızlı küçülme, hemen ardından gelen küçük bir pikte tekrar büyümeyi tetikler. Bu sırada yeni pod’ların “ısınma” süresi varsa (JIT, cache, bağlantı havuzu), kullanıcı gecikmesi dalgalanır. Scale-down stabilizasyon penceresi ve politikalar çoğu zaman scale-up’tan daha kritiktir.

3) PDB, disruption ve minimum replika çelişkisi

PodDisruptionBudget (PDB) ile “en az şu kadar pod ayakta kalsın” dediğinizde, autoscaler küçülmek istese bile bazı evictions/rollout’lar bloke olabilir. Bu durum cluster tarafında “boş node kapatılamıyor” gibi maliyet artıran sonuçlara da yol açabilir.

4) Metrik güvenilirliği: eksik veri ile yanlış karar

Metrik pipeline’ında kesinti, HPA’nın eski değerlerle karar vermesine veya “unknown” davranışıyla beklemesine neden olur. Özellikle custom metrics’te rate-limit, veri gecikmesi ve etiket patlaması (yüksek cardinality) sürpriz üretir.

5) Trafik dağılımı: load balancer ve hazır olma sinyali

Yeni pod ayağa kalksa bile readiness doğru kurgulanmadıysa trafik erken gelebilir. Bu, yeni replika “hazır değilken” yük almasına ve hata oranının artmasına neden olur. Autoscaling ile birlikte readiness ve liveness kontrolleri daha hassas hale gelir.

6) Stateful servislerde VPA Auto ile yeniden başlatma riski

VPA Auto, requests’i uygulamak için pod’u yeniden başlatabilir. Stateful servislerde yeniden başlatma, lider seçimleri ve replikasyon gecikmeleri gibi zincir etkiler doğurabilir. Bu nedenle önce Off/Initial ile önerileri doğrulamak, sonra kontrollü geçiş yapmak daha güvenlidir.

7) Cluster Autoscaler ile “node yok” döngüsü

HPA replika artırır ama node’larda kapasite yoksa pod’lar Pending kalır. Cluster Autoscaler yeni node ekler, fakat node’lar gelene kadar gecikme büyür. Ayrıca requests çok şişkinse yeni node’lar verimsiz dolabilir. Burada pod boyutu ile node çeşitliliği birlikte ele alınmalıdır.

8) QoS sınıfları ve eviction davranışı

Requests/limits değerleri QoS sınıflarını etkiler. Node baskısında hangi pod’ların önce evict edileceği bu sınıflara göre değişir. Yanlış limit stratejisi, kritik olmayan bir iş yükünün kritik bir servisi baskılamasına zemin hazırlayabilir.

9) Uygulama içi bottleneck: ölçeklemek işe yaramıyor

Bağlantı havuzu, dış servis kotası, tekil lock veya paylaşılan bir DB dar boğazı varsa replika artırmak yalnızca daha fazla bekleyen istek üretir. Bu yüzden autoscaling kararları, uygulamanın yatay büyümeye gerçekten uygun olup olmadığıyla birlikte değerlendirilmelidir.

10) Yanlış SLO hedefi: metrik ile kullanıcı deneyimi uyuşmuyor

CPU “iyi” görünürken kullanıcı gecikmesi kötü olabilir. Ölçekleme hedefi, mümkünse kullanıcıya yakın bir SLI’a bağlanmalıdır: hata oranı, gecikme, kuyruk derinliği, throughput gibi. Doğru sinyal, doğru autoscaling demektir.

Pratik guardrail’ler: üretimde daha güvenli ölçekleme için kontrol listesi

İyi bir autoscaling tasarımı, yalnızca HPA/VPA manifestlerinden ibaret değildir. Aşağıdaki kontrol listesi, çoğu takımın üretimde daha öngörülebilir davranış elde etmesine yardımcı olur.

Requests taban çizgisi: ölç, sonra sabitle

1. Önce gözlem: birkaç gün gerçek yükte CPU/RAM dağılımlarını çıkarın.
2. p50/p90 ile taban request belirleyin, p95/p99 için burst alanı bırakın.
3. VPA Off modunda önerileri izleyin, min/max guardrail ekleyin.

Requests’i rastgele seçmek, HPA davranışını rastgeleleştirir. Özellikle CPU utilization hedefi kullanıyorsanız bu adım kritik bir ön koşuldur.

HPA behavior: scale-up hızlı, scale-down temkinli

Scale-up tarafında kısa sürede kapasite kazanmak isteyebilirsiniz; ancak scale-down tarafında sabırlı olmak çoğu uygulama için daha stabil bir deneyim üretir. Stabilizasyon penceresini, uygulamanın ısınma süresi ve trafik dalgalanmasına göre ayarlayın. Ayrıca maksimum büyüme hızını kısıtlamak, ani metrik sapmalarında “patlamayı” önler.

Gözlemleme ve hata ayıklama: neden ölçekledi ya da ölçeklemedi?

Autoscaling sorunlarında ilk ihtiyaç, karar anını aydınlatmaktır: HPA hangi metriği, hangi değerle gördü; VPA hangi öneriyi üretti; scheduler neden yerleştiremedi; node baskısı var mıydı? Bu soruların yanıtı yoksa çözüm “manifest deneme-yanılma”ya döner.

HPA olayları ve metrik anlık görüntüsü

HPA event’leri, hedef metrik, mevcut değer ve hesaplanan replika önerisini genellikle açıkça yazar. Birçok durumda problem metrik kaynağının gecikmesi veya requests normalize hatasıdır. Bu yüzden HPA’yı incelerken deployment manifestindeki kaynak değerlerini de birlikte okuyun.

VPA önerileri ve güncelleme davranışı

VPA’nın recommendation çıktısı, hedef container’lar için CPU/RAM önerilerini ve tarihsel gözlemi verir. Auto modunda “neden restart oldu?” sorusu için update policy ve eviction davranışını kontrol edin. Özellikle bakım pencereleri dışında istenmeyen yeniden başlatmalar ciddi etki yaratabilir.

Örnek strateji: HPA + VPA + Cluster Autoscaler birlikte nasıl tasarlanır?

Gerçekçi bir senaryoda çoğu ekip, üçlü kombinasyonu kullanır. Buradaki hedef, katmanların birbirini “şaşırtmaması”dır. Önerilen akış şu şekilde kurgulanabilir:

• VPA Off ile önerileri toplayın; min/max sınırlarıyla aşırılıkları engelleyin.
• Requests’i kontrollü güncelleyip HPA davranışını gözlemleyin.
• HPA’yı mümkünse kullanıcıya yakın bir sinyal (kuyruk, gecikme, throughput) ile sürün.
• Cluster Autoscaler için node pool stratejisini, pod boyutlarına uyumlu planlayın.

Birlikte çalışma için küçük ama etkili ayarlar

Stabilizasyon pencereleri, pod ısınma süresi, readiness ve rate limit gibi detaylar, autoscaling’in hissedilen kalitesini belirler. Ayrıca uygulama tarafında connection pool, timeouts ve retry politikaları ölçekleme anında davranışı dramatik biçimde etkiler. Autoscaling’i yalnızca Kubernetes özelliği değil, uçtan uca bir dayanıklılık tasarımı olarak ele almak gerekir.

Sonuç: doğru sinyal, doğru guardrail, sakin bir sistem

HPA ve VPA, Kubernetes’te kapasiteyi otomatik yönetmenin güçlü araçlarıdır; fakat yanlış metrik, yanlış requests ve agresif politikalarla birleştiğinde sisteminizi “kendi kendine sorun üreten” bir hale getirebilir. Kubernetes autoscaling başarısı; doğru sinyali seçmek, gecikmeleri hesaba katmak, stabilizasyon ve sınırlar koymak, sonra da gözlemleme ile sürekli iyileştirmekten geçer.

Bir sonraki adım olarak, önce mevcut kaynak taleplerinizi ve HPA hedeflerinizi gerçek yük profiliyle doğrulayın. Ardından VPA’yı Off/Initial ile devreye alıp önerileri güvenli aralıklarda tutun. En önemlisi, ölçekleme kararlarını kullanıcı deneyimiyle ilişkilendirip metriklerinizi bu hedefe göre düzenleyin.

İpucu: Ölçekleme sorunlarını çözerken tek bir manifest yerine “metrik kaynağı + requests/limits + davranış politikaları + uygulama ısınması” dörtlüsünü birlikte değerlendirin. Bu yaklaşım, dalgalanmayı azaltıp daha öngörülebilir bir sistem sağlar.