Belajar KEDA - Konsep Dasar & Arsitektur Utama

#Pendahuluan

Di episode 1 kita sudah paham mengapa KEDA ada: menskalakan workload berdasarkan event, bukan CPU, dan menurunkan replika hingga nol saat tidak ada pekerjaan. Pertanyaan berikutnya yang wajar muncul adalah: bagaimana caranya?

Episode 2 membuka kap mesin. Kita akan melihat tiga komponen yang berjalan di namespace keda setelah install, memahami peran masing-masing, lalu berkenalan dengan objek-objek Custom Resource (CRD) yang akan kalian tulis terus-menerus di sisa seri ini.

#Arsitektur Tiga Komponen

Saat kalian install KEDA via Helm, ada tiga Deployment yang muncul: keda-operator, keda-metrics-server, dan keda-admission-webhooks. Masing-masing punya peran yang sangat berbeda.

#Operator: Mengelola ScaledObject dan ScaledJob

Operator adalah otak KEDA. Ia menjalankan reconciliation loop khas pola operator Kubernetes: terus-menerus membandingkan kondisi nyata dengan apa yang dideklarasikan dalam CRD. Ketika kalian membuat ScaledObject atau ScaledJob, operator yang bertanggung jawab melakukan dua hal penting:

1. Membuat dan mengelola HPA yang sesuai secara otomatis.
2. Memastikan HPA itu terus selaras dengan konfigurasi di CRD — misalnya saat maxReplicaCount diubah.

Contoh ScaledObject sederhana

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-worker-scaledobject
spec:
  scaleTargetRef:
    name: order-worker
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders

Perhatikan: kalian tidak pernah membuat HPA secara manual untuk workload ini. HPA dibuat dan dikelola operator, dan perintah berikut akan menampilkannya:

Melihat HPA yang dibuat otomatis oleh KEDA

kubectl get hpa
kubectl get scaledobject
kubectl describe scaledobject order-worker-scaledobject

#Metrics Server: Jembatan Menuju HPA

Komponen kedua adalah keda-metrics-server. Ia mengimplementasikan External Metrics API Kubernetes. Ketika HPA (yang dibuat operator) butuh angka, ia bertanya ke keda-metrics-server, yang lalu menghubungi scaler yang sesuai untuk mengambil nilai aktual — misalnya panjang queue RabbitMQ — dan mengembalikannya dalam bentuk yang dipahami HPA.

Inilah alasan KEDA "menyatu" dengan ekosistem Kubernetes tanpa plugin tambahan: HPA tidak tahu dan tidak peduli bahwa datanya berasal dari Kafka atau SQS. Yang ia lihat hanyalah metrik eksternal bernama tertentu.

#Admission Webhooks: Penjaga Gerbang Validasi

Komponen ketiga adalah keda-admission-webhooks. Seperti namanya, ia menyediakan endpoint webhook yang dipanggil Kubernetes setiap kali ada objek KEDA yang dibuat atau diubah. Tugasnya validasi: apakah nilai maxReplicaCount lebih besar dari minReplicaCount? Apakah nama scaler yang dipakai memang terdaftar? Jika tidak valid, objek ditolak sebelum sempat merusak state cluster.

#Alur Permintaan Metrik, Langkah Demi Langkah

Untuk memahami betapa rapi desain KEDA, ikuti satu siklus permintaan metrik dari awal sampai akhir:

1. Operator mendeteksi ScaledObject baru, lalu membuat HPA yang menargetkan deployment milik kalian.
2. Sesuai pollingInterval, HPA meminta nilai metrik eksternal ke keda-metrics-server.
3. Metrics server menentukan scaler yang sesuai (misalnya RabbitMQ), lalu memanggil API broker untuk mengambil queue depth aktual.
4. Nilai aktual dibandingkan dengan threshold dari trigger.
5. HPA menghitung jumlah replika yang dibutuhkan dan mengubah deployment kalian.

Alur data dari event hingga replika

RabbitMQ --> keda-metrics-server --> External Metrics API --> HPA --> Deployment

Kunci dari seluruh alur ini: HPA tetap menjadi satu-satunya pengambil keputusan final. KEDA hanya menyediakan data yang lebih relevan. Karena itulah perilaku naik-turun replika masih bisa disetel lewat mekanisme HPA seperti behavior untuk scaleUp dan scaleDown — akan kita bahas di episode 11.

#Komponen Utama dalam Bentuk CRD

Semua konfigurasi KEDA dilakukan lewat empat Custom Resource. Menguasai keempatnya berarti menguasai 80 persen KEDA.

#ScaledObject

ScaledObject (disertai scaledobjects.keda.sh) mengatur autoscaling untuk workload berkelanjutan seperti Deployment, StatefulSet, atau ReplicaSet. Field utamanya adalah scaleTargetRef (menunjuk workload), pollingInterval, cooldownPeriod, minReplicaCount, maxReplicaCount, dan triggers. Episode 4 membahasnya tuntas.

#ScaledJob

ScaledJob mengatur autoscaling Job (Kubernetes Jobs untuk workload batch). Beda mendasarnya dengan ScaledObject: alih-alih menambah/mengurangi replika pod yang sudah ada, KEDA membuat Job baru ketika ada event — perilaku yang lebih cocok untuk satu-satunya tugas yang punya awal dan akhir.

#TriggerAuthentication dan ClusterTriggerAuthentication

Sebagian besar scaler memerlukan kredensial untuk mengakses sumber event — misalnya secret SQS atau certificate Kafka. Kredensial itu didefinisikan di TriggerAuthentication (berlaku di satu namespace) atau ClusterTriggerAuthentication (berlaku lintas namespace), lalu dirujuk dari triggers di ScaledObject. Seluk-beluknya kita bedah di episode 6.

#70+ Scalers

Bagian yang membuat KEDA begitu menarik: koleksi scaler yang sudah jadi. Setiap scaler adalah implementasi untuk satu sumber metrik spesifik:

Dua trigger dalam satu ScaledObject

spec:
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: sum(rate(worker_processed_total[2m]))
        threshold: "10"
    - type: cron
      metadata:
        timezone: Asia/Jakarta
        start: "0 8 * * *"
        end: "0 18 * * *"

Pada tahun 2026, koleksinya sudah lebih dari 70 scalers, dan bisa dikelompokkan berdasarkan kategori:

Seluruh daftar resmi selalu bisa dicek di dokumentasi keda.sh. Tiga komponen arsitektur tadi ditambah empat CRD ini adalah satu paket yang akan kalian gunakan di setiap episode berikutnya.

#Penutup

Episode 2 memberi peta arsitektur KEDA. Berikut yang wajib kalian bawa:

• Operator mengelola ScaledObject/ScaledJob dan otomatis membuat HPA.
• Metrics server menyuplai metrik eksternal ke HPA via External Metrics API.
• Admission webhooks memvalidasi konfigurasi sebelum diterapkan.
• Empat CRD utama: ScaledObject, ScaledJob, TriggerAuthentication, dan ClusterTriggerAuthentication, didukung 70+ scalers.

Di episode 3 kita turun ke lapangan: instalasi KEDA dari awal dengan Helm, opsi konfigurasi via --set, dan alternatif instalasi berbasis manifest untuk alur GitOps.