Yükleniyor
RabbitMQ, Apache Kafka, Redis Streams veya AWS SQS kuyruklarını dinleyen arka plan mikroservisleriniz için standart Kubernetes HPA'nın talep ettiği 7/24 boşta pod rezerve etme israfı yerine, CNCF mezunu açık kaynaklı KEDA (Kubernetes Event-driven Autoscaling) kullanın. Kuyruklar boşken podları tam 0'a indirerek (Scale-to-Zero) kümenizdeki sunucu düğüm (node) sayısını ve yıllık bulut maliyetinizi nasıl yarıya düşüreceğinizi hesaplayın.
Kubernetes kümenizdeki arka plan kuyruk tüketicilerini, kaynak taleplerini ve günlük boşta kalma süresini belirleyin.
resources.requests.cpu değeri.resources.requests.memory değeri.Aylık $144 (4 sunucu düğümü)
Aylık $72 (2 sunucu düğümü)
Sunucu altyapı faturasında %50 net kâr
45 boşta pod yerine 0 pod (Scale-to-Zero)
Standart HPA'nın kuyruklar boşken 7/24 rezerve ettiği işlemci/bellek israfı ve KEDA'nın sağladığı tasarruf.
22.5 vCPU Cores
Günde 14 saat boşta bekleyen podlar
45 GB RAM
KEDA olmadan node'larda kilitli kalan bellek
0 Pod (Scale-to-Zero)
Kuyrukta mesaj yokken kaynak tüketimi sıfırlanır
~65 MB RAM
Go dilinde yazılmış ultra hafif tekil operatör
# keda-scaledobject.yaml - Production Scale-to-Zero Worker Deployment
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: order-worker-scaler
namespace: production
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: order-worker-deployment
pollingInterval: 15 # 15 saniyede bir kuyruk kontrol edilir
cooldownPeriod: 180 # Kuyruk bosaldiktan 3 dk sonra 0 poda indir
minReplicaCount: 0 # KULLANILMAYAN SAATLERDE TAM SIFIRA INDIR (Scale to Zero)
maxReplicaCount: 15 # Pik trafiginde cikilabilecek tavan pod sayisi
advanced:
restoreToOriginalReplicaCount: true
horizontalPodAutoscalerConfig:
behavior:
scaleDown:
stabilizationWindowSeconds: 120
triggers:
- type: rabbitmq
metadata:
queueName: order-processing-queue
mode: QueueLength
value: "10" # Her 10 mesaj icin 1 pod ayaga kaldir
authenticationRef:
name: keda-rabbitmq-authKubernetes'in yerleşik Horizontal Pod Autoscaler (HPA) bileşeni, podların ortalama CPU ve Bellek kullanımına göre ölçekleme yapar. Ancak arka plan kuyruk tüketicilerinde (consumer) CPU kullanımı kuyruktaki bekleyen iş hacmini (queue lag / depth) yansıtmaz. Daha da kritik olanı, standart HPA minReplicas değerini 0 yapamaz; her servisin en az 1-3 podu 7/24 çalışmak zorundadır.
20 farklı asenkron kuyruk servisiniz olduğunda ve her birinden en az 3 kopya çalıştığında, 60 adet pod geceleri ve sakin saatlerde hiçbir mesaj işlememesine rağmen onlarca vCPU çekirdeğini ve gigabaytlarca RAM'i bloke eder. AWS EKS veya GCP GKE'de bu durum, ayda $1.000 ila $3.000+ fazladan EC2/Compute Engine sunucu faturası anlamına gelir.
KEDA (CNCF Graduated), harici kuyruk metriklerini doğrudan okur (RabbitMQ vhost, Kafka consumer group lag, Redis pending list). Kuyrukta mesaj yokken Deployment'ı 0 kopyaya (Scale to Zero) indirir. İlk mesaj geldiğinde KEDA Activator pod'u anında 1'e çıkarır, kuyruk derinliği arttıkça 15-20 saniye içinde dinamik olarak tavan replica sayısına ulaştırır. Küme düğümleri (Cluster Autoscaler veya Karpenter) boşalan sunucuları otomatik kapatarak devasa tasarruf sağlar.
cooldownPeriod: 180 ile kuyruk boşaldıktan sonra 3 dk bekleyip ani dalgalanmalarda gereksiz kapanmaları önleyin.Soru: KEDA ile 0'a inen podlar yeni mesaj geldiğinde ne kadar sürede ayağa kalkar (cold start)?
Cevap: Düğüm üzerinde konteyner imajı önbellekteyse (cached), Go veya Node.js tabanlı bir kuyruk worker'ı 1 ila 3 saniye içinde çalışır duruma gelir. KEDA varsayılan olarak 15 saniyede bir (pollingInterval: 15) kuyrukları kontrol eder; bu aralık 5-10 saniyeye indirilerek gecikme daha da azaltılabilir.
Soru: VDS üzerindeki hafif K3s veya Talos kümelerinde KEDA çalışır mı?
Cevap: Evet, KEDA standart bir Kubernetes Custom Resource Definition (CRD) ve operatörüdür. K3s, Talos Linux, MicroK8s veya vanilla Kubernetes kümelerinde Helm 3 ile 1 dakikada kurulur ve tek bir pod olarak (~65 MB RAM) sorunsuz çalışır.
Soru: KEDA kullanmak bir Kubernetes kümesinde ne kadar tasarruf sağlar?
Cevap: Günde 12-16 saat boyunca boş veya düşük trafik alan kuyruk sistemlerinde sunucu düğümü ihtiyacı %50 ila %75 oranında azalır. 15-20 mikroservislik bir mimaride AWS EKS üzerinde yılda ~$4.000 ila $12.000, VDS Kubernetes üzerinde ise ~$1.500 ila $3.500 net sunucu tasarrufu sağlanır.