Belajar KEDA - Sejarah, Latar Belakang & Mengapa Membutuhkan KEDA

#Pendahuluan

Di episode 0 kita sudah menyiapkan cluster dan KEDA terinstall dengan benar. Kali ini kita mundur dulu dari praktik dan menjawab pertanyaan yang paling mendasar: kenapa KEDA ada? Untuk memahami sebuah alat, cara tercepat adalah memahami masalah yang gagal dipecahkan oleh alat sebelumnya.

Masalah itu sederhana tapi menyakitkan: workload event-driven — workload yang "bangun" karena ada pesan masuk — tidak bisa diskalakan dengan baik oleh alat autoscaling Kubernetes standar. Episode ini menelusuri evolusi autoscaling, kelahiran KEDA, dan memetakan posisinya di antara HPA murni serta custom-metrics-adapter.

#Evolusi Autoscaling di Kubernetes

Autoscaling Kubernetes pada dasarnya punya dua lapisan: Horizontal Pod Autoscaler (HPA) untuk jumlah pod, dan Cluster Autoscaler/Karpenter untuk jumlah node. Kita fokus ke HPA dulu.

#Dua Lapis Autoscaling: Pod dan Node

Penting untuk memisahkan dua tingkatan sebelum melangkah lebih jauh. HPA mengatur jumlah pod dalam sebuah Deployment berdasarkan metrik. Di atasnya ada lapisan kedua: Cluster Autoscaler atau Karpenter yang mengatur jumlah node — memastikan cluster punya kapasitas menampung pod yang baru ditambahkan. KEDA bekerja di lapisan pertama (pod); episode 16 nanti akan menunjukkan bagaimana KEDA berdampingan dengan Karpenter sehingga node tersedia dalam hitungan detik.

#HPA Berbasis CPU dan Memory Itu Reaktif

HPA bekerja dengan metrik resource: seberapa tinggi pemakaian CPU atau memory pod dibanding requests yang dideklarasikan. Mekanisme ini elegan untuk web service klasik, tetapi bermasalah untuk workload event-driven karena satu alasan utama: reaktif, bukan proaktif.

Coba bayangkan sebuah consumer queue yang menganggur: CPU-nya nyaris 0 persen. Lalu puluhan ribu pesan masuk dalam sekejap. CPU consumer baru mulai naik setelah pesan masuk dan pekerjaan dijalankan. Artinya HPA baru bereaksi setelah sistem sudah telanjur terbebani — scaling selalu telat satu langkah. Sebaliknya, queue bisa penuh sementara CPU tetap rendah karena consumer sedang menunggu respon jaringan atau I/O.

Masalah HPA reaktif pada workload event-driven

Queue penuh ---> HPA belum bereaksi (CPU rendah) ---> Consumer kewalahan
Pesan kosong ---> HPA belum turun (CPU masih tinggi) ---> Replika nganggur

Kesimpulannya: untuk workload yang digerakkan event, sinyal yang benar bukanlah CPU, melainkan jumlah event yang menunggu. Queue depth, consumer lag, atau panjang antrian.

#Kelahiran KEDA

Pada 2019, Microsoft dan Red Hat meluncurkan proyek bernama KEDA — Kubernetes Event-driven Autoscaling. Gagasannya revolusioner: bukan mengganti HPA, tapi menempatkan adapter yang menerjemahkan metrik event dari berbagai sumber menjadi metrik yang bisa dipahami HPA.

Perjalanannya cepat. KEDA masuk sebagai sandbox project CNCF, kemudian diumumkan graduated pada Agustus 2023 — status paling tinggi untuk sebuah proyek CNCF, artinya sudah dianggap matang dan siap produksi. Versi v2.x aktif terus dikembangkan sejak 2023 hingga saat ini, dengan rilis stabil terbaru v2.20.2 (Juli 2026).

helm list -n keda
kubectl get deploy -n keda
kubectl get crd | grep keda

Output helm list -n keda akan menunjukkan versi chart; pastikan itu versi terbaru sebelum melanjutkan.

#Dari Sandbox Menjadi Proyek Graduated

Perjalanan menuju status graduated bukan sekadar formalitas. Setelah diluncurkan pada 2019, KEDA diterima sebagai sandbox project CNCF pada tahun yang sama, lalu naik ke tahap incubating, sebelum akhirnya dinyatakan graduated pada Agustus 2023. Status ini berarti proyek dianggap matang secara governance, stabilitas, dan adopsi produksi. Kontribusinya pun jauh melampaui Microsoft dan Red Hat — AWS, Google, dan puluhan organisasi lain ikut serta dan memakai KEDA di produksi.

Versi v2.x yang aktif saat ini terus menambah scaler dan perbaikan stabilitas setiap beberapa bulan. Rilis terbaru, v2.20.2, dirilis pada Juli 2026, dan seperti yang akan kita lihat di episode 20, setiap rilis biasanya membawa scaler tambahan plus penyempurnaan pada metrics server dan operator.

#Masalah yang Diselesaikan KEDA

#Scaling Berdasarkan Event, Bukan CPU

KEDA menskalakan berdasarkan jumlah event/backlog dari sumber mana pun: panjang queue SQS, consumer lag Kafka, queue depth RabbitMQ, atau hasil query Prometheus. Ini membuat scaling menjadi proaktif — replika naik karena sinyal penyebab muncul, bukan karena efek (CPU) sudah terjadi. Di episode 4 dan 5 kita akan melihat persis bagaimana sinyal ini dikonversi menjadi jumlah replika.

#Scale-to-Zero: Menghemat hingga 40-60%

Ini mungkin fitur yang paling banyak dicari orang. Karena keputusan scaling berasal dari ada-tidaknya event, KEDA bisa menurunkan replika menjadi nol saat tidak ada pekerjaan. Untuk workload yang hidup idle hampir sepanjang hari — batch job, AI inference, worker malam — penghematan idle compute 40-60 persen bukanlah klaim yang berlebihan. Detail kapan aman melakukannya akan kita bedah tuntas di episode 5.

#Integrasi Native dengan HPA

Alih-alih menciptakan sistem autoscaling baru, KEDA memanfaatkan infrastruktur yang sudah ada: ia otomatis membuat HPA dan menjadi metrics server yang menyuplainya lewat External Metrics API. Tidak ada dependensi eksternal tambahan, dan perilaku naik-turun replika tetap dikendalikan oleh mekanisme HPA yang sudah kalian kenal.

#Kapan Cukup dengan HPA Saja

Sebagai penyeimbang, tidak semua workload butuh KEDA. Gunakan HPA murni jika metrik target kalian memang CPU/memory atau metrik kustom yang sudah tersedia — misalnya API backend yang dipakai terus-menerus. Mengganti HPA dengan KEDA untuk workload seperti ini hanya menambah kompleksitas operator tanpa manfaat yang berarti.

Sebaliknya, pertimbangkan KEDA jika setidaknya salah satu kondisi ini berlaku:

• Workload dihidupkan oleh event eksternal (queue, stream, HTTP pending requests).
• Kalian ingin scale-to-zero saat tidak ada pekerjaan.
• Sumber metrik beragam dan bisa berubah-ubah (Prometheus, SQS, Kafka, database).
• Kalian ingin satu platform autoscaling yang konsisten untuk semua workload.

Rule of thumb: HPA itu palu, KEDA itu kotak peralatan. Palu cukup untuk pakunya; ambil kotak peralatan saat jenis pekerjaannya beragam.

#KEDA vs Pendekatan Lain

Supaya posisi KEDA jelas, bandingkan tiga opsi umum:

HPA murni bagus untuk web service klasik. custom-metrics-adapter (misal Prometheus adapter) menyelesaikan masalah sumber metrik, tapi tidak menyelesaikan masalah scale-to-zero dan mengharuskan kalian memelihara adapter sendiri. KEDA menggabungkan keduanya: satu titik integrasi untuk puluhan sumber metrik, plus kemampuan menurunkan replika hingga nol.

#Sinyal yang Tepat untuk Workload Event-Driven

Ada analogi sederhana untuk menutup episode ini: autoscaling berbasis CPU itu seperti menambah kasir setelah antrian pembeli mengular sampai pintu. KEDA membaca jumlah antrian itu sendiri — sebelum sempat mengular. Untuk workload event-driven, sinyal yang tepat adalah jumlah pekerjaan yang menunggu, bukan seberapa sibuk pekerja saat ini.

Sinyal HPA   : cpu lebih dari 70 persen ---> tambah pod (reaktif)
Sinyal KEDA  : queue depth lebih dari 20 ---> tambah pod (proaktif)

#Penutup

Episode 1 menyelesaikan pertanyaan "kenapa". Berikut yang wajib kalian bawa:

• HPA berbasis CPU bersifat reaktif dan tidak cocok untuk workload event-driven.
• KEDA lahir 2019 dari Microsoft dan Red Hat; graduated CNCF pada Agustus 2023.
• Versi stabil terbaru adalah v2.20.2 (Juli 2026).
• KEDA menskalakan berdasarkan event, mendukung scale-to-zero, dan berintegrasi native dengan HPA.

Di episode 2 kita membongkar bagian dalam mesinnya: bagaimana operator, metrics server, dan admission webhooks bekerja sama, serta apa itu ScaledObject, ScaledJob, dan TriggerAuthentication.