Kubernetes'te Pod Otomatik Ölçeklendirme: HPA, VPA ve KEDA Arasında Doğru Seçim

Sorunun kaynağı: tek metrikle ölçeklendirme çabuk tükeniyor

Bir servisin kaç kopya (pod) çalıştırması gerektiğini elle belirlemek, trafik sabitken işe yarar. Trafik dalgalandığında ya fazladan kapasite için para öder durursunuz ya da yoğun saatte servis darlığa girer. Kubernetes'in otomatik ölçeklendirme araçları bu kararı sizin yerinize, gerçek zamanlı metriklere bakarak verir. Ama "otomatik ölçeklendirme" tek bir araç değil, üç farklı sorunu çözen üç farklı mekanizmadır: HPA (Horizontal Pod Autoscaler) kopya sayısını değiştirir, VPA (Vertical Pod Autoscaler) her kopyaya ayrılan kaynağı değiştirir, KEDA ise olay tabanlı iş yüklerini kuyruk derinliği veya dış metriklere göre ölçekler. Bu üçünü birbirinin yerine kullanmaya çalışmak, çoğu ölçeklendirme sorununun kök nedenidir.

HPA: CPU ve bellek bazlı yatay ölçeklendirme

HPA, autoscaling/v2 API grubunda tanımlanır ve varsayılan davranışı CPU kullanımına göre kopya sayısını artırıp azaltmaktır. Temel bir tanım şöyle görünür:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Bu yapı basit ama üç şeye bağımlı: metrics-server'ın küme içinde kurulu olması, her podun resources.requests alanının doğru doldurulmuş olması (HPA yüzdeyi bu istekten hesaplar) ve metriğin CPU/bellek dışında bir şey olması gerektiğinde özel bir metrik adaptörünün (Prometheus Adapter gibi) devreye girmesi. requests alanı boş veya gerçek kullanımdan çok uzak yazılmışsa HPA'nın hesapladığı yüzde anlamsızlaşır; bu, sahada en sık görülen HPA tuzağıdır ve HPA "çalışmıyor" değil, "yanlış girdiyle çalışıyor" olur.

HPA'nın gizli ayarı: davranış (behavior) ve flapping

HPA'nın en az bilinen ama en çok tuzak barındıran kısmı behavior alanıdır. Varsayılan ayarlarla bırakılan bir HPA, kısa süreli bir CPU sıçramasında hemen kopya ekler, sıçrama geçince de hemen kopya düşürür; bu davranış "flapping" olarak bilinir ve özellikle isteklerin bağlantı havuzuna dayandığı servislerde her ölçek değişiminde bağlantıların yeniden kurulmasına, dolayısıyla gecikme artışına yol açar. behavior.scaleDown.stabilizationWindowSeconds ile son N saniyedeki en yüksek talebi baz alarak düşürmeyi geciktirebilir, behavior.scaleUp tarafında ise ani artışlarda kaç kopyanın birden ekleneceğini sınırlayabilirsiniz:

  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
    scaleUp:
      stabilizationWindowSeconds: 0

Bu ayarı hiç dokunmadan bırakmak, "HPA kararsız davranıyor" şikayetinin en sık nedenidir; sorun HPA'da değil, varsayılan pencerenin sizin trafik desenize uymamasındadır. Aynı bölümde birden fazla metrik de tanımlanabilir (örneğin CPU ve istek başına gecikme birlikte); HPA bu durumda her metriğin önerdiği kopya sayısının en yükseğini uygular, en düşüğünü değil. Bu davranışı bilmeden CPU'ya ek olarak gecikme metriği eklemek, beklenenden daha erken ölçeklenen ama asla beklenenden geç ölçeklenmeyen bir sistem üretir.

VPA: doğru boyutu bulmak, ama bir bedelle

HPA kopya sayısını değiştirirken, bazı iş yüklerinde asıl sorun kopya sayısı değil, her kopyaya verilen CPU/bellek miktarının yanlış tahmin edilmiş olmasıdır. VPA bu tahmini geçmiş kullanım verisinden çıkarır ve resources.requests/limits değerlerini önerir veya otomatik uygular:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  updatePolicy:
    updateMode: "Auto"

Buradaki updateMode: "Auto" seçeneği tarihsel olarak VPA'nın en tartışmalı kısmıdır: geleneksel VPA, kaynak isteğini değiştirmek için podu yeniden başlatır. Bir podun rastgele bir anda yeniden başlaması, tek kopya çalışan bir iş yükünde kısa kesintiye yol açar; arkada birden çok kopya varsa PodDisruptionBudget doğru ayarlanmadığında aynı anda birden fazla podun yeniden başlaması servis kapasitesini geçici olarak düşürür. Bu yüzden VPA'yı üretimde updateMode: "Auto" ile değil, önce "Off" modunda (yalnızca öneri üretir, uygulamaz) çalıştırıp önerilen değerleri elle gözden geçirerek kullanmak daha güvenli bir başlangıçtır. HPA ile aynı kaynak metriğinde (CPU) aynı anda çalıştırmak da önerilmez: ikisi de kaynak isteğini/kopya sayısını aynı sinyale göre değiştirmeye çalışınca birbirinin kararını geçersiz kılan bir döngüye girebilirler.

KEDA: olay tabanlı iş yükleri ve sıfıra ölçekleme

HPA ve VPA, sürekli çalışan ve kaynak tüketimiyle ölçülebilen servisler için tasarlandı. Ama bir kuyruktan mesaj işleyen bir tüketici, mesaj yokken CPU tüketmez; CPU'ya bakan bir HPA bu iş yükünü hiç ölçeklemez çünkü ölçüm zaten yanlış sinyale bakıyordur. KEDA burada araya girer: kopya sayısını CPU değil, kuyruk derinliği, bir mesajlaşma sisteminin metriği, bir cron zamanlaması veya Prometheus sorgusu gibi dış sinyallere göre belirler ve iş yükü tamamen boşken kopya sayısını sıfıra indirebilir.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: worker
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: rabbitmq
      metadata:
        queueName: jobs
        mode: QueueLength
        value: "5"

Sıfıra ölçekleme, boşta duran kapasiteye ödeme yapmamak için cazip görünür ama bir bedeli vardır: sıfırdan ilk podun ayağa kalkması (cold start) saniyeler sürebilir, imaj büyükse ve başlatma sırasında ağır bir kurulum adımı varsa bu süre daha da uzar. Gecikmeye toleranslı arka plan işleri için sıfıra ölçekleme mantıklıdır; kullanıcının isteğe anında yanıt beklediği bir yol için minReplicaCount değerini en az 1'de tutmak, maliyetten kazandığınızdan fazlasını gecikme olarak geri ödemenizi önler.

Hangisini ne zaman seçmeli

Sürekli çalışan, istek bazlı ve CPU/bellek tüketimiyle yükü doğru yansıtan servisler için HPA hâlâ doğru varsayılandır; kurulumu basittir ve ekosistemde en iyi test edilmiş yoldur. Kaynak isteklerinin doğru boyutlandırılıp boyutlandırılmadığından şüpheniz varsa VPA'yı önce salt-öneri modunda çalıştırıp gerçek kullanım verisiyle karar verin, otomatik uygulamaya production'da temkinli geçin. Kuyruk, mesaj sistemi, zamanlanmış iş veya herhangi bir dış metrikle tetiklenen iş yükleri için KEDA'yı tercih edin; KEDA aslında HPA'nın üstüne bir metrik kaynağı ekler, onun yerine geçmez (KEDA kurulduğunda arka planda kendi HPA nesnesini oluşturur).

Ne zaman hiçbirini kurmamalı

Yükü gün içinde neredeyse sabit olan, trafik artışının önceden bilindiği (örneğin belirli saatte tetiklenen toplu bir iş) ya da tek bir kopyanın rahatça kaldırdığı küçük bir servise otomatik ölçeklendirme kurmak, çözülmemiş bir sorunu çözüyormuş gibi görünen bir karmaşıklık katmanı ekler. Bu durumlarda sabit replicas değeri ve gerekirse basit bir zamanlanmış kubectl scale komutu, üç ayrı kontrolcünün etkileşimini debug etmekten daha ucuza gelir. Otomatik ölçeklendirmenin maliyeti sadece CPU/bellek değil, sisteme eklenen bir davranış katmanıdır: metrikler gecikirse, stabilizasyon penceresi yanlış ayarlanırsa ya da bir kopya aniden ölçeklenip geri düşerse (flapping), bu davranışı anlayacak birinin olması gerekir. Küçük ve öngörülebilir bir yük için o kişinin zamanı, otomasyondan daha değerlidir.