KEDA Nedir? Kubernetes’te Event-Driven Autoscaling

Meta Description

KEDA nedir? Kubernetes’te kuyruk/event trafiğine göre otomatik ölçekleme kurun. HPA’nın yetmediği yerde maliyeti düşürün.

Giriş (Introduction)

KEDA (Kubernetes Event-Driven Autoscaling), Kubernetes üzerinde uygulamalarınızı CPU/RAM yerine event kaynağına göre ölçeklemenizi sağlar. “Queue büyüdü, consumer sayısını artır”; “trafik sıfırlandı, pod sayısını 0’a indir” gibi senaryoları HPA ile tam ve doğru yapmak çoğu zaman zordur.

E-ticaret, ödeme, bildirim, arka plan işleyiciler (worker) ve entegrasyon servislerinde yük genellikle kuyruk mesaj sayısı, Kafka lag, HTTP istek sayısı veya cron tabanlı yoğunluk gibi sinyallerle gelir. CPU düşük görünürken kuyruk şişebilir; ya da tam tersi.

Bu yazıda KEDA nedir sorusunu netleştirip, gerçek hayatta neden işe yaradığını, nasıl kurulduğunu ve örnek bir ScaledObject ile adım adım nasıl çalıştığını öğreneceksiniz.

KEDA Nedir? (Temel Mantık)

KEDA, Kubernetes’e “event-driven” ölçekleme yeteneği ekleyen bir projedir. Temel yaklaşım:

• Bir event kaynağı seçersiniz (RabbitMQ, Kafka, Azure Service Bus, AWS SQS, Prometheus, Redis Streams, HTTP, cron vb.).
• KEDA, bu kaynağı sürekli izler.
• Belirlediğiniz eşiklere göre deployment’ınızı 0’dan N’e kadar ölçekler.

Klasik HPA, çoğunlukla resource metric (CPU/RAM) veya custom metric ile çalışır. KEDA ise “iş var mı?” sorusunu işin kendisine (event kaynağına) sorar.

Bunu neden yapmalıyım? Çünkü worker’larda asıl problem CPU değil, “bekleyen iş miktarı”dır. KEDA, doğru sinyale göre ölçekleyerek hem gecikmeyi düşürür hem de boşta maliyeti azaltır.

HPA vs KEDA: Ne Zaman Hangisi?

Aşağıdaki tablo hızlı karar vermenize yardım eder:

Kısa kural:

• Request-driven servislerde HPA çoğu zaman yeterli.
• Event/queue-driven işlerde KEDA genelde daha doğru.

KEDA’nın Mimari Parçaları (Kısaca)

KEDA kurulunca cluster’a birkaç temel bileşen eklenir:

• keda-operator: ScaledObject/ScaledJob kaynaklarını okur, HPA ve ölçekleme mantığını yönetir.
• metrics-apiserver: KEDA’nın ürettiği metrikleri Kubernetes’e sunar.
• Scalers: Her event kaynağı için “ölçüm” yapan adaptörler (Kafka, RabbitMQ, Prometheus vb.).

Önemli nokta: KEDA çoğu senaryoda arka planda HPA oluşturur, fakat metrik kaynağı CPU değil event’tir.

Adım Adım Kurulum: KEDA’yı Cluster’a Ekleyin

Aşağıdaki örnek Helm ile kurulum içindir (en yaygın yol):

1) Helm repo ekleyin

helm repo add kedacore https://kedacore.github.io/charts
helm repo update

2) KEDA’yı kurun

kubectl create namespace keda
helm install keda kedacore/keda \
  --namespace keda

3) Kurulumu doğrulayın

kubectl get pods -n keda
kubectl get crd | grep keda

Beklenen: scaledobjects.keda.sh, scaledjobs.keda.sh gibi CRD’ler görünmeli.

Örnek: RabbitMQ Kuyruğuna Göre Worker Ölçekleme

Gerçek hayatta çok sık görülen bir senaryo: sipariş sonrası e-posta gönderimi, fatura üretimi, entegrasyon çağrıları gibi işler bir kuyruğa akar.

Varsayım:

• email-worker adında bir Deployment’ınız var.
• RabbitMQ’da email_queue kuyruğu var.
• Kuyrukta mesaj sayısı arttıkça pod sayısı artsın.
• Trafik sıfır olunca pod sayısı 0 olsun.

1) Deployment (örnek)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: email-worker
spec:
  replicas: 0
  selector:
    matchLabels:
      app: email-worker
  template:
    metadata:
      labels:
        app: email-worker
    spec:
      containers:
        - name: worker
          image: your-registry/email-worker:1.0.0
          env:
            - name: RABBITMQ_URL
              valueFrom:
                secretKeyRef:
                  name: rabbitmq-secret
                  key: url

Not: replicas: 0 başlatmak normal. KEDA iş geldikçe kaldırır.

2) TriggerAuthentication (secret yönetimi)

KEDA’nın RabbitMQ’ya bağlanması için secret’ı referanslayalım:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: rabbitmq-auth
spec:
  secretTargetRef:
    - parameter: host
      name: rabbitmq-secret
      key: url

3) ScaledObject (asıl ölçekleme kuralı)

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: email-worker-scaledobject
spec:
  scaleTargetRef:
    name: email-worker
  minReplicaCount: 0
  maxReplicaCount: 20
  pollingInterval: 10

# saniye
  cooldownPeriod: 60

# saniye
  triggers:
    - type: rabbitmq
      metadata:
        queueName: email_queue
        queueLength: "50"

# 50 mesaj/pod gibi düşünün
      authenticationRef:
        name: rabbitmq-auth

Bu ne yapar?

• KEDA her 10 saniyede bir kuyruğu kontrol eder.
• Kuyrukta biriken iş arttıkça pod sayısını artırır.
• Kuyruk boşalınca 60 saniye “cooldown” sonrası tekrar azaltır.
• İş yoksa 0 pod ile maliyeti minimize eder.

4) Uygulama

kubectl apply -f deployment.yaml
kubectl apply -f triggerauth.yaml
kubectl apply -f scaledobject.yaml

5) Gözlemleme

kubectl get scaledobjects
kubectl describe scaledobject email-worker-scaledobject
kubectl get hpa
kubectl get pods -w

İnce Ayar: Doğru Eşik ve Stabil Ölçekleme

KEDA “kur ve unut” değil; doğru ayar çok fark ettirir.

queueLength nasıl seçilir?

• Worker’ınız ortalama 1 mesajı kaç saniyede işliyor?
• Kabul edilebilir maksimum gecikme kaç saniye/dakika?

Basit yaklaşım:

• Mesaj işleme süresi: ~200ms
• 1 pod saniyede ~5 mesaj
• 10 pod saniyede ~50 mesaj

Bu durumda queueLength: "50" kaba bir başlangıç olabilir; sonra ölçüp ayarlarsınız.

pollingInterval ve cooldownPeriod

• pollingInterval düşük olursa daha hızlı tepki, daha çok metrik sorgusu.
• cooldownPeriod düşük olursa “zıplama” (flapping) artabilir.

Öneri:

• Trafiğiniz dalgalıysa cooldown’u biraz yüksek tutun (60–180s).

Gerçek Hayat Örneği: Kampanya Günü Bildirim Kuyruğu

Kampanya gününde push/e-posta bildirimleri 5 dakikada 20 bin mesaja fırlıyor.

• HPA sadece CPU’ya bakarsa worker CPU düşük kalabilir (I/O bekliyor olabilir), kuyruk büyür.
• KEDA kuyruk derinliğini görür, worker’ları hızla artırır.
• Kampanya biter, kuyruk boşalır, pod sayısı 0 olur.

Sonuç: Daha düşük maliyet + daha düşük gecikme + daha az operasyonel müdahale.

Sık Sorulan Sorular (FAQ)

1) KEDA nedir ve HPA’nın yerini mi alır?

KEDA, çoğu senaryoda HPA ile birlikte çalışır. Farkı, ölçekleme metriklerini event kaynaklarından üretmesidir.

2) KEDA ile “scale to zero” güvenli mi?

Evet, özellikle worker tarzı servislerde çok yaygındır. Ancak connection warm-up, cold start ve ilk mesaj gecikmesi etkisini ölçmelisiniz.

3) KEDA sadece kuyruklar için mi?

Hayır. Prometheus metrikleri, cron, HTTP, database bazı senaryolar ve birçok sistem için scaler vardır. En güçlü olduğu yer event/queue temelli iş yükleridir.

4) KEDA production’da kullanılabilir mi?

Evet, yaygın şekilde kullanılıyor. Yine de kaynak limitleri, maxReplicaCount, hata durumları ve gözlemlenebilirlik (log/metric) tarafını planlamak gerekir.

Sonuç

KEDA nedir? KEDA, Kubernetes’te uygulamalarınızı CPU yerine event sinyallerine göre ölçekleyen, özellikle worker ve kuyruk bazlı mimarilerde müthiş maliyet/performans avantajı sağlayan bir çözümdür.

Bu rehberde:

• KEDA’nın mantığını,
• HPA’dan farkını,
• Helm ile kurulum adımlarını,
• RabbitMQ kuyruğuna göre ölçeklenen gerçek bir örneği uçtan uca gördünüz.

Siz hangi event kaynağıyla ölçeklemek istiyorsunuz (Kafka lag, SQS, Prometheus, cron)? Yorum yazın; bir sonraki yazıda aynı senaryoya uygun ScaledObject örneğini paylaşayım.