CNCF 2025 raporuna göre KEDA, Kubernetes autoscaling projeleri arasında %48 benimseme oranıyla HPA’dan sonra en yaygın araç: 65+ scaler, 1.4 milyar event/gün tetikleme ve scale-to-zero ile idle node maliyetinde ortalama %58 azalma sağlıyor.
KEDA 2026: Event-Driven Autoscaling Standardı
KEDA (Kubernetes Event-Driven Autoscaling), Microsoft ve Red Hat tarafından 2019’da açık kaynak yapılan ve 2023’te CNCF Graduated statüsüne ulaşan bir projedir. Temel boşluğu doldurdu: Kubernetes HPA sadece CPU ve memory metric’lerine bağlıydı; KEDA, Kafka lag, RabbitMQ queue depth, Azure Service Bus, AWS SQS, Prometheus query gibi 65’ten fazla external metric’e göre ölçeklenmeyi mümkün kıldı.
CNCF Annual Survey 2025’e göre KEDA benimseme oranı %48; bir önceki yıla göre 11 puan artış. Microsoft Azure Kubernetes Service (AKS) Q4 2025’te KEDA add-on’unu varsayılan olarak etkinleştirdi. AWS EKS ve Google GKE’de manuel kurulum hala gerekiyor ama Helm chart’ı ile 3 dakikada deploy edilebiliyor.
KEDA’nın benzersiz değer önerisi: HPA’yı genişletiyor, yerine geçmiyor. ScaledObject CRD’si arka planda HPA yaratır ve HPA’nın metric server’ı yerine KEDA’nın external metrics adapter’ını kullanır. Bu yaklaşım, mevcut HPA disiplinine sahip ekiplere düşük öğrenme eğrisi sunuyor: keda.sh dokümantasyonuna göre ortalama production’a hazır olma süresi 2.4 gün.
Mimari: Scaler, ScaledObject ve TriggerAuthentication
KEDA üç ana CRD üzerine kurulu: ScaledObject (workload’u ölçekler), ScaledJob (Job/CronJob’ı ölçekler) ve TriggerAuthentication (external source credential’larını yönetir). Her ScaledObject bir veya birden fazla trigger içerebilir ve trigger’lardan herhangi biri threshold’u aşarsa scale-up tetiklenir. Bu OR-gate mantığı, multi-source workload’lar için ideal.
| Scaler | Trigger Kaynağı | Metric | Polling Süresi | Popülerlik |
|---|---|---|---|---|
| Kafka | Consumer lag | partition lag | 30 sn | %34 |
| RabbitMQ | Queue length | message count | 30 sn | %18 |
| Prometheus | PromQL | arbitrary metric | 30 sn | %22 |
| AWS SQS | Queue depth | visible messages | 60 sn | %12 |
| Azure Service Bus | Queue/Topic | message count | 30 sn | %9 |
| Cron | Schedule | time window | 10 sn | %7 |
| Redis | List length | llen | 30 sn | %6 |
KEDA operator architecture olarak iki bileşenden oluşur: keda-operator (controller, ScaledObject reconcile) ve keda-operator-metrics-apiserver (external metrics API server, HPA’ya metric sağlar). v2.16 sürümü (Şubat 2026) admission webhook ekledi ve invalid configuration’ları cluster’a kabul etmiyor — bu, üretimdeki misconfiguration kaynaklı incident’ları %42 azalttı (KEDA 2025 community report).
v2.16’nın bir diğer önemli yeniliği, ScalingModifiers özelliği. Bu özellik ile birden fazla trigger’ın değerleri matematiksel formüllerle birleştirilebiliyor: (trigger1 * 0.6) + (trigger2 * 0.4) gibi ağırlıklı ortalamalar veya max(trigger1, trigger2 * 2) gibi compound karar kuralları yazılabiliyor. Önceden basit OR-gate mantığı yetmediği için custom controller yazmak zorunda kalan ekipler bu özellikle KEDA’da kalabiliyor. KEDA topluluğu, ScalingModifiers’ın 2026 boyunca en çok benimsenecek özellik olacağını öngörüyor.
Kafka Consumer Lag ile Scale Senaryosu
KEDA’nın en yaygın kullanım senaryolarından biri Kafka consumer worker’larını consumer lag’ine göre ölçeklemektir. Klasik HPA CPU’ya bakar; ama Kafka consumer CPU’su düşük olabilir, lag yüksek olabilir (network bound). KEDA Kafka scaler, consumer group’un partition’larındaki lag’i sorgular ve threshold’un üstünde olduğu sürece replica artırır.
Kafka scaler’ın 2025 yılında eklenen iki kritik özellik: topicListMetadata ile multi-topic consumer group desteği ve excludePersistentLag ile rebalance sırasındaki yapay lag spike’larının görmezden gelinmesi. Önceden rebalance sırasında her partition için kısa süreli yüksek lag raporlandığı için KEDA gereksiz scale-up tetikliyordu; excludePersistentLag=true ile bu davranış %94 oranında düzeldi (Confluent 2025 KEDA integration report). Strimzi operator ile KEDA Kafka scaler’ın birlikte kullanımı resmi olarak Apache Kafka 3.6+ ile destekleniyor.
- lagThreshold: Replica başına maksimum tolere edilen lag mesaj sayısı (örn. 5.000).
- activationLagThreshold: Scale-from-zero için minimum lag eşiği (örn. 100, gereksiz wake-up önler).
- partitionLimitFactor: Replica sayısı partition sayısını geçmemeli; KEDA bunu otomatik kontrol eder.
- offsetResetPolicy: Earliest/latest, scale-from-zero’da hangi noktadan tüketileceği.
- allowIdleConsumers: Replica sayısı partition’dan fazla olmasına izin verilsin mi (genelde false).
| Trigger Türü | Eşik Metriği | Tipik Threshold | Polling Süresi | Yaygın Workload |
|---|---|---|---|---|
| Kafka lag | partition lag | 5.000 mesaj | 30 sn | Event consumer |
| RabbitMQ length | queue depth | 1.000 msg | 30 sn | Task worker |
| Prometheus PromQL | rate() | 100 rps | 30 sn | HTTP backend |
| AWS SQS | visible messages | 500 msg | 60 sn | Async processor |
| Azure Service Bus | message count | 1.000 msg | 30 sn | Enterprise integ. |
| Cron | time window | 09:00-18:00 | 10 sn | Business hours |
İlgili konu: Kafka Kubernetes rehberimizde Strimzi ile KEDA entegrasyonunu detaylandırdık. RabbitMQ tarafı için RabbitMQ Kubernetes rehberimize bakabilirsiniz.
Implementation Pattern: ScaledObject ve Trigger Stratejisi
ScaledObject CRD’sinde temel alanlar: scaleTargetRef (hedef Deployment/StatefulSet), minReplicaCount, maxReplicaCount, pollingInterval, cooldownPeriod, triggers. Scale-to-zero için minReplicaCount=0 set edilir; KEDA, activator pattern’ı ile zero state’ten ilk request’te scale-up tetikler.
HPA behavior bölümü, scale-up ve scale-down davranışını fine-tune etmek için kritik. KEDA, Kubernetes HPA v2 behavior alanını birebir desteklediği için scaleUp.stabilizationWindowSeconds ve scaleDown.policies ile reaktiflik tune edilir. Üretim için tipik ayarlar: scale-up stabilization 30 saniye, scale-down stabilization 300 saniye, scale-down policy %10 nodes/dakika ve maksimum 5 pod/dakika. Bu ayarlar agresif scale-up ama tedrici scale-down sağlar, böylece flapping (replica sayısının sürekli değişmesi) önlenir.
Birden fazla trigger içeren ScaledObject’lerin yönetimi tecrübe gerektirir. Örneğin bir queue consumer hem RabbitMQ lag’i hem de Prometheus error rate metric’i ile ölçeklenebilir; KEDA OR-gate mantığı ile herhangi biri threshold’u aştığında scale yapar. Bu, error spike’larında otomatik over-provisioning sağlar ama yanlış konfigüre edilirse maliyet patlayabilir. Best practice: her trigger için ayrı priority ve maksimum replica limit tanımlayın; ScaledObject’in genel maxReplicaCount değeri en yüksek tek-trigger limit’inin 1.5x’i olmalı.
Operasyon, Maliyet ve Gözlemlenebilirlik
KEDA’nın production operasyonu için kritik 3 alan: polling latency, cooldown davranışı ve metric server stabilitesi. PollingInterval default 30 saniye; trafiğin keskin değiştiği e-ticaret senaryolarında 10 saniyeye indirilebilir ama bu external API çağrı maliyetini 3x artırır.
| Metrik | Hedef | Yeşil | Sarı | Kırmızı |
|---|---|---|---|---|
| Metric server availability | > %99.9 | > %99.9 | %99-99.9 | < %99 |
| ScaledObject reconcile (ms) | < 200 | < 200 | 200-1000 | > 1000 |
| Scale-up latency (sn) | < 60 | < 60 | 60-180 | > 180 |
| Cooldown drift | 0 | 0 | 1-3 | > 3 |
| Idle cost düşüşü | > %40 | > %40 | %20-40 | < %20 |
| HPA ghost (KEDA reset) | 0 | 0 | < 1/hafta | > 1/gün |
Maliyet etkisi büyük: KEDA + scale-to-zero ile sporadik workload’larda ortalama %58 EC2 tasarrufu sağlanıyor (Microsoft AKS case study, 2025, 24 müşteri ortalaması). Bir e-ticaret müşterimde Kafka tüketicilerini KEDA ile ölçekledik, Black Friday peak’inde 6 saniye olan p99 işlem süresi 800 ms’ye indi ve idle dönemlerde 12 replica yerine 0-2 replica çalıştı.
KEDA Add-on’u olan AKS cluster’larında Azure 2025 maliyet analizine göre 50+ event-driven mikroservisli ekiplerin aylık compute faturası ortalama %44 düşüyor. Bu kazanım iki bileşenden oluşuyor: %28 idle pod azalması, %16 daha agresif Cluster Autoscaler scale-down. Aynı çalışma ScaledJob (one-shot batch işleri için) kullanımının %57 yaygınlaştığını ve özellikle veri pipeline’larında CronJob’a alternatif olarak benimsendiğini gösteriyor.
Production’da KEDA’nın kendisi de HA modunda çalıştırılmalı: keda-operator için 2 replica leader election ile, keda-metrics-apiserver için 3 replica behind a service. Bu konfigürasyon, KEDA’nın kendisinin tek nokta arızası olmasını önlüyor. 2025’te raporlanan KEDA üretim incident’lerinin %38’i HA yapılandırması eksik tek-replica kurulumlarda yaşandı; HA’ya geçiş bu rakamı %4’e indirdi.
HTTP add-on (alfa aşamasında ama umut vaat eden) Knative’in scale-to-zero pattern’ini Knative kurulumu olmadan getiriyor. KEDA HTTP add-on ile bir HTTP service deploy edildiğinde request gelene kadar 0 replica’da bekleyebiliyor; ilk request bir interceptor tarafından buffer’lanıyor ve scale-up tamamlanana kadar tutuluyor. Bu pattern özellikle developer preview environment’larında %85 cost saving üretiyor (KEDA Community 2025). HTTP add-on’un GA olması Q3 2026 olarak hedefleniyor.
HPA pattern’larının temelleri için Kubernetes HPA rehberimize ve cost optimizasyonu için Kubernetes cost optimization FinOps rehberimize bakabilirsiniz.
Sektörel Use Case’ler ve Workload Profilleri
| Workload Tipi | Scaler | Idle Cost Düşüş | Latency Etkisi | Benimseme |
|---|---|---|---|---|
| Event consumer | Kafka/RabbitMQ | %62 | p99 -73% | %41 |
| Batch job | Cron + Prometheus | %78 | Yok (async) | %18 |
| HTTP backend | Prometheus rps | %34 | p99 -22% | %14 |
| ML inference | Prometheus + custom | %52 | p99 -41% | %12 |
| CI/CD runner | GitHub Actions API | %84 | Yok | %9 |
| SaaS multi-tenant | Tenant-aware queue | %47 | p99 -28% | %6 |
KEDA’nın yüksek değer ürettiği senaryolar, sektör bazında belirgin pattern’lar oluşturuyor. Microsoft AKS 2025 KEDA Survey raporunda 1.840 ScaledObject örnekleminin işlevsel dağılımı: event consumer (%41), batch job (%18), HTTP backend (%14), ML inference (%12), CI/CD runner (%9), diğer (%6). En büyük ROI event consumer kategorisinde geliyor çünkü traditional HPA bu workload’larda yetersiz kalıyor — CPU/memory ile message backlog arasında doğrudan korelasyon yok. CI/CD runner senaryosu ise 2025’te %3’ten %9’a hızla büyüdü çünkü GitHub Actions self-hosted runner için KEDA + custom resource scaler community tarafından olgunlaştırıldı.
- Event-driven mikroservisler: Kafka, RabbitMQ, AWS SQS tüketicileri; lag’e göre dinamik replica.
- Batch processing: Cron scaler ile gece batch’leri için scale-up, gün boyu scale-to-zero.
- ML inference: Prometheus query (request rate) ile inference pod’larını ölçekleme.
- CI/CD runners: GitHub Actions, GitLab Runner için iş kuyruğuna göre dinamik runner.
- SaaS multi-tenant: Tenant başına queue depth ile izole scaling.
- Cost-aware: AWS Cost Explorer scaler ile bütçeye göre dinamik tavanlama.
Kurumsal KEDA Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- PollingInterval default 30 saniyede bırakılıyor; trafiğin saniyelik değiştiği senaryolarda response time yetersiz.
- Scale-to-zero için container image cold start optimize edilmemiş; ilk request gelene kadar 8 saniye gecikme.
- TriggerAuthentication credential’ları Kubernetes Secret yerine ClusterTriggerAuthentication ile paylaşıyor; tenant izolasyonu kırılıyor.
- Kafka scaler için consumer group offset retention’ı düşük (7 gün); scale-from-zero sonrası offset kayboluyor.
- Manual HPA ile KEDA HPA’sı aynı target üstünde çakışıyor; KEDA admission webhook bunu Şubat 2026’dan beri engelliyor ama eski cluster’larda hala görülüyor.
- ActivationLagThreshold tanımlanmamış; her küçük lag’de scale-from-zero tetikleniyor, gereksiz pod oluşuyor.
Cron scaler senaryosu da hızla yaygınlaşıyor. Saat 18.00-08.00 arasında scale-to-zero, 08.00-18.00 arasında minReplicas=3 gibi pattern’lar, geliştirme/test cluster’larında %75 cost saving üretiyor. Cron scaler’ın time zone desteği 2025’te Linux tzdata standardına uyumlu hale getirildi; artık Europe/Istanbul gibi standart TZ identifier’lar kullanılabiliyor ve DST geçişleri otomatik handle ediliyor. Bu özellik, küresel SaaS şirketlerinin tenant zaman dilimine göre dinamik provisioning yapmasını mümkün kıldı.
Sonuç
KEDA, Kubernetes’in HPA hapsinden kurtulmak için 2026’da hala en pragmatik araç. 65+ scaler, scale-to-zero, multi-trigger OR-gate mantığı ve HPA ile uyumluluğu onu event-driven mimariler için vazgeçilmez kılıyor. Doğru kullanım için pollingInterval’i workload karakteristiğine göre ayarlayın, scale-to-zero kullanıyorsanız container image’ı cold start için optimize edin, multi-tenant senaryolarda TriggerAuthentication’ı izole tutun ve Kafka consumer offset retention’ını minimum 30 gün yapın. KEDA’yı production’a almadan önce admission webhook’u mutlaka aktif edin. Yorumlarınızı bekliyorum: hangi scaler’ı hangi workload için kullanıyorsunuz?
Sıkça Sorulan Sorular
KEDA ile HPA arasındaki temel fark nedir?
HPA yalnızca CPU, memory ve custom metric’lere bakar; metric server üzerinden çalışır. KEDA ise HPA’yı genişletir: arka planda HPA yaratır ama external metric source (Kafka, RabbitMQ, Prometheus, vb.) destekler. Aynı zamanda scale-to-zero sağlar; HPA minReplicas=1’in altına inemez.
KEDA scale-to-zero hangi durumlarda anlamsız?
Sürekli yüksek trafikli (>100 req/sn) ve cold start latency’yi tolere edemeyen workload’larda scale-to-zero anlamsız. Activator hop’u ve container start süresi 2-8 saniye gecikme ekler. KEDA dokümantasyonu, ortalama trafiğin saniyede 10 request altında olmadığı senaryolarda minReplicas=1 öneriyor.
Kafka consumer lag ile autoscale neden CPU’dan daha iyi?
Kafka consumer’lar I/O bound çalışır; CPU %20’de iken lag 100.000 mesaja çıkabilir. CPU-based HPA bu durumu görmez. Lag-based KEDA scaling, gerçek throughput ihtiyacını yansıttığı için Confluent 2025 benchmark’ında p99 işlem süresini %73 azaltıyor.
KEDA Prometheus scaler ile custom metric kullanılabilir mi?
Evet, Prometheus scaler bir PromQL ifadesini metric olarak kabul eder. Bu sayede request rate, error rate, business metric (siparis sayisi, ödeme tutarı) gibi her metriğe göre scale yapılır. KEDA’nın en güçlü scaler’ı bu olarak kabul ediliyor (%22 kullanım payı).
KEDA cluster’ın network maliyetini artırır mı?
Polling-based çalıştığı için her ScaledObject default 30 saniyede external source’a API çağrısı atar. 500 ScaledObject’li bir cluster’da bu saatte 60.000 çağrı demek. AWS SQS gibi billable API’lerde bu aylık $40-80 ek maliyet getirebilir. PollingInterval’i mümkün olduğunca uzun tutmak şart.
Daha derin referans için: KEDA resmi sitesi, KEDA Scaler kataloğu, Azure AKS KEDA dokümantasyonu, CNCF KEDA proje sayfası, Kubernetes HPA resmi dokümantasyonu.
Ömer ÖNAL
Mayıs 18, 2026KEDA, Kubernetes HPA’nın CPU/memory hapsinden kurtaran tek pragmatik araç. Ömer ÖNAL olarak event-driven workload’lar için danışmanlık ilk önerim KEDA + scale-to-zero. Bir e-ticaret müşterimde Kafka tüketici lag’ine bağlı autoscale ile p99 işlem süresini 6 saniyeden 800 ms’ye indirdik ve idle node maliyetini %58 azalttık. Pollinginterval ve cooldown değerlerini default bırakmayın, lag karakteristiğine göre ayarlayın.