# KEDA: Autoscaling Event-Driven & Scale-to-Zero di K8s

> Cara saya autoscale Kubernetes dengan KEDA berdasarkan kedalaman antrean, lag Kafka, Prometheus, dan cron alih-alih CPU — menskalakan worker event-driven ke nol, beserta trade-off cold-start yang menyertainya.

URL: https://www.matthewswong.com/id/blog/keda-event-driven-autoscaling-kubernetes/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-08-01
- Updated: 2026-08-01
- Category: DevOps

> **Key takeaway:** KEDA (Kubernetes Event-Driven Autoscaling) adalah add-on lulusan CNCF yang menskalakan workload berdasarkan sinyal eksternal seperti kedalaman antrean, lag Kafka, kueri Prometheus, atau jadwal cron, bukan CPU. KEDA membungkus Horizontal Pod Autoscaler lewat ScaledObject dan dapat menskalakan deployment yang menganggur hingga nol replika untuk menekan biaya.

Kebanyakan saran autoscaling Kubernetes berhenti di Horizontal Pod Autoscaler yang memantau CPU. Itu cocok untuk layanan web yang CPU-nya naik seiring trafik, tetapi gagal untuk paruh sistem saya yang event-driven: worker yang menguras antrean RabbitMQ, consumer yang mengejar lag Kafka, batch job tengah malam. Pod-pod itu bisa mentok di CPU tinggi padahal backlog kosong, atau menganggur di CPU rendah padahal ribuan pesan menumpuk. CPU jelas sinyal yang keliru.

KEDA mengatasinya dengan menskalakan berdasarkan sumber event itu sendiri. KEDA lahir sebagai kolaborasi Microsoft dan Red Hat pada 2019, masuk CNCF Sandbox pada Maret 2020, pindah ke Incubator pada Agustus 2021, dan lulus sebagai proyek CNCF pada 22 Agustus 2023 — tingkat kematangan yang sama dengan Kubernetes sendiri. KEDA berjalan di produksi pada organisasi seperti FedEx, Grafana Labs, Reddit, dan Xbox, jadi ini bukan proyek coba-coba.

## Mengapa CPU adalah sinyal yang keliru untuk kerja event-driven

HPA menjawab satu pertanyaan: apakah pod saya sibuk? Untuk API yang melayani request, itu proksi beban yang lumayan, karena lebih banyak request berarti lebih banyak CPU. Tetapi consumer antrean memisahkan kedatangan dari pemrosesan. Sepuluh ribu pesan bisa datang dalam satu ledakan sementara satu pod yang berjalan mengunyahnya pada CPU yang stabil dan biasa saja. HPA tidak melihat apa pun yang mengkhawatirkan dan tidak pernah scale out, sehingga backlog dan latensi Anda sama-sama naik sementara dashboard tampak tenang.

Yang sebenarnya Anda pedulikan adalah backlog, bukan CPU. Sinyal penskalaan yang tepat adalah kedalaman antrean, lag consumer Kafka, metrik Prometheus, atau bahkan jam. KEDA memungkinkan Anda menskalakan langsung berdasarkan angka-angka itu, dan dapat menahan deployment di nol replika saat tidak ada pekerjaan sama sekali — sesuatu yang tidak bisa dilakukan HPA biasa, karena lantainya adalah satu.

## Bagaimana KEDA membungkus HPA alih-alih menggantikannya

KEDA tidak menulis ulang autoscaling; ia memperluas apa yang sudah dimiliki Kubernetes. Anda memasangnya sebagai operator, dan ia membagi tugas menjadi dua. Operator KEDA menangani tepi aktivasi — membawa deployment dari nol ke satu saat event pertama tiba, dan kembali dari satu ke nol saat sumber sepi. Segala hal di atas satu replika didelegasikan ke HPA standar yang dibuat dan dikelola KEDA untuk Anda.

Jembatannya adalah KEDA metrics API server, yang mengekspos angka yang di-polling dari sumber event Anda (Kafka, RabbitMQ, SQS, Prometheus, dan lainnya) sebagai external metrics Kubernetes. HPA yang dihasilkan membaca metrik itu persis seperti membaca CPU, lalu menskalakan satu-ke-N terhadap threshold Anda. Anda mendeskripsikan semua ini dalam satu custom resource, yaitu ScaledObject, dan KEDA menjaga HPA di baliknya tetap sinkron dengannya.

> Karena KEDA menggerakkan HPA sungguhan, semua yang sudah Anda ketahui tentang perilaku HPA tetap berlaku. Anda bisa menyetel stabilization window serta laju scale-up atau scale-down lewat bagian advanced pada ScaledObject, dan perilaku penskalaan kustom apa pun yang Anda atur langsung mengalir ke HPA yang dihasilkan — tanpa objek HPA terpisah untuk dirawat.

## ScaledObject, dan menskalakan ke nol

Sebuah ScaledObject menunjuk workload yang akan diskalakan dan mendaftar satu atau lebih trigger. Dua field yang paling penting untuk biaya adalah minReplicaCount, yang default-nya nol dan itulah yang mengaktifkan scale-to-zero, serta maxReplicaCount, yang membatasi HPA di 100 secara default. KEDA memeriksa tiap trigger pada pollingInterval (30 detik secara default) dan, begitu sebuah sumber menganggur selama cooldownPeriod (300 detik secara default), menskalakan workload kembali ke nol.

Field threshold adalah nilai target per replika: dengan threshold 50 dan 500 pesan menunggu, HPA membidik sekitar sepuluh replika. activationThreshold yang terpisah hanya mengontrol tepi nol-ke-satu — ia mencegah KEDA membangunkan seluruh deployment hanya untuk satu pesan nyasar, yang penting saat cold start mahal. Setel di atas nol untuk workload apa pun yang bangunnya tidak gratis.

## Scaler: kedalaman antrean, lag Kafka, Prometheus, cron

Scaler adalah konektor yang membaca satu jenis sumber event. KEDA hadir dengan lebih dari 60 scaler bawaan saat lulus dan terus menambahnya, sehingga sebagian besar sumber umum tercakup langsung. Yang paling sering saya pakai:

- Antrean pesan — RabbitMQ, AWS SQS, Azure Service Bus, dan lainnya menskalakan berdasarkan jumlah pesan yang menunggu, sehingga replika mengikuti backlog nyata.
- Kafka — menskalakan berdasarkan lag consumer group, menambah pod saat group tertinggal dari partisinya dan menghapusnya begitu ia menyusul.
- Prometheus — scaler paling fleksibel: kueri PromQL apa pun menjadi sinyal penskalaan, sehingga Anda bisa menskalakan berdasarkan request per detik, latensi p95, atau metrik bisnis kustom.
- Cron — menskalakan ke jumlah replika tetap antara waktu mulai dan selesai dalam timezone tertentu, ideal untuk pre-warming sebelum puncak harian yang sudah diketahui dan kembali ke nol pada malam hari.

Trigger bisa digabung. Anda dapat menaruh trigger cron dan trigger Prometheus pada ScaledObject yang sama; KEDA mengambil jumlah replika tertinggi yang diminta trigger aktif mana pun. Kombinasi itulah cara saya menghangatkan layanan ke baseline sebelum kesibukan pagi dengan cron, sambil tetap membiarkan metrik langsung menskalakannya lebih jauh jika permintaan nyata melampaui perkiraan.

## Trade-off cold-start yang tidak bisa Anda lewati

Scale-to-zero baru benar-benar hemat ketika waktu menganggur murah dan latensi tidak penting. Saat deployment berada di nol, event pertama tidak mendapat respons instan — ia harus menunggu polling interval KEDA agar terdeteksi, lalu pod harus dijadwalkan, image ditarik jika belum ter-cache, container dijalankan, dan readiness probe terpenuhi. Untuk runtime yang berat, itu bisa menambah latensi beberapa detik hingga puluhan detik pada request pertama setelah menganggur.

> Jangan pernah menskalakan ke nol layanan yang sensitif latensi dan menghadap pengguna. Penundaan cold-start jatuh pada request pengguna sungguhan. Pertahankan minReplicaCount di satu atau lebih untuk apa pun di jalur interaktif, dan simpan scale-to-zero untuk worker latar belakang, consumer batch, dan job internal di mana waktu bangun beberapa detik tak terlihat.

## HPA berbasis CPU vs KEDA: apa bedanya

| Aspek | HPA berbasis CPU atau memori | KEDA (event-driven) |
| --- | --- | --- |
| Menskalakan berdasarkan | Utilisasi CPU atau memori | Kedalaman antrean, lag Kafka, PromQL, cron, dan 60-plus sumber |
| Replika minimum | Satu — tidak bisa mencapai nol | Nol — scale-to-zero sungguhan |
| Reaksi terhadap backlog | Tidak langsung, hanya setelah CPU naik | Langsung, pada metrik backlog itu sendiri |
| Biaya menganggur | Membayar setidaknya satu pod | Tidak ada pod berjalan saat menganggur |
| Cara berjalan | Bawaan Kubernetes | Operator add-on plus ScaledObject yang menggerakkan HPA |
| Cold start | Tidak ada — selalu hangat | Event pertama setelah menganggur menunggu pod menyala |

Aturan praktis saya: jika pekerjaannya menghadap pengguna dan terikat latensi, biarkan HPA menskalakannya berdasarkan CPU dan pertahankan lantai yang hangat. Jika pekerjaannya event-driven dan meledak-ledak — consumer antrean, pipeline Kafka, batch terjadwal — serahkan ke KEDA, pilih scaler yang cocok dengan sinyal nyata, dan biarkan turun ke nol di antara ledakan. Mulai dengan satu worker non-kritis, pasang satu trigger, dan amati ia bangun dan tidur sebelum Anda memercayakannya pada yang lebih sibuk.

## Sources

- KEDA — Konsep dan arsitektur (dokumentasi resmi)
- KEDA — Katalog scaler bawaan (dokumentasi resmi)
- CNCF — Pengumuman kelulusan KEDA
- KEDA — Kelulusan menjadi proyek lulusan CNCF

## Source links

- https://keda.sh/docs/latest/concepts/
- https://keda.sh/docs/latest/scalers/
- https://www.cncf.io/announcements/2023/08/22/cloud-native-computing-foundation-announces-graduation-of-kubernetes-autoscaler-keda/
- https://keda.sh/blog/2023-08-22-keda-cncf-graduation/

## FAQ

### Apa itu KEDA di Kubernetes?

KEDA (Kubernetes Event-Driven Autoscaling) adalah add-on lulusan CNCF yang menskalakan workload berdasarkan sumber event eksternal seperti kedalaman antrean, lag Kafka, kueri Prometheus, atau jadwal cron, bukan sekadar CPU atau memori. KEDA bekerja bersama Horizontal Pod Autoscaler, bukan menggantikannya.

### Bagaimana KEDA bekerja dengan Horizontal Pod Autoscaler?

KEDA tidak menggantikan HPA; ia menggerakkannya. Operator KEDA menangani tepi aktivasi (nol-ke-satu dan satu-ke-nol), sementara HPA standar yang dibuat KEDA menangani penskalaan satu-ke-N. Sebuah metrics API server mengekspos angka sumber event sebagai external metrics Kubernetes yang dibaca HPA seperti membaca CPU.

### Bisakah KEDA menskalakan deployment ke nol replika?

Bisa. Menyetel minReplicaCount ke 0 (nilai default-nya) pada ScaledObject mengaktifkan scale-to-zero sungguhan. Ketika sumber event menganggur selama cooldownPeriod, KEDA menurunkan workload ke nol pod, sehingga worker yang menganggur tidak berbiaya hingga event berikutnya tiba.

### Apa trade-off cold-start pada scale-to-zero KEDA?

Saat deployment berada di nol, event pertama harus menunggu polling interval KEDA, lalu pod dijadwalkan, image ditarik jika belum ter-cache, container dijalankan, dan readiness probe terpenuhi. Itu menambah latensi beberapa detik hingga puluhan detik, jadi jangan menskalakan layanan sensitif latensi yang menghadap pengguna ke nol.

### Apakah KEDA proyek CNCF?

Ya. KEDA dimulai sebagai kolaborasi Microsoft dan Red Hat pada 2019, masuk CNCF Sandbox pada Maret 2020, pindah ke Incubator pada Agustus 2021, dan lulus sebagai proyek CNCF pada 22 Agustus 2023. KEDA berjalan di produksi pada organisasi seperti FedEx, Grafana Labs, Reddit, dan Xbox.

---

- HTML version: https://www.matthewswong.com/id/blog/keda-event-driven-autoscaling-kubernetes/
- English: https://www.matthewswong.com/en/blog/keda-event-driven-autoscaling-kubernetes/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json