Belajar KEDA - Pre-Requisites Skill & Setup Environment

#Pendahuluan

Selamat datang di seri Belajar KEDA! Selama 22 episode ke depan, kita akan membangun pemahaman dari nol tentang KEDA (Kubernetes-based Event Driven Autoscaling): operator open-source yang membuat workload Kubernetes bisa menskalakan diri berdasarkan event — bukan sekadar CPU atau memory.

Namun ada satu syarat yang tidak bisa ditawar: KEDA berdiri di persimpangan dua dunia, yaitu Kubernetes dan konsep event-driven (queue, stream, message broker). Kalau salah satu fondasinya belum kuat, materi berikutnya akan terasa seperti membaca buku resep tanpa pernah memasak. Karena itu episode 0 ini khusus menyiapkan seluruh fondasi: skill yang wajib dimiliki, tools yang harus diinstall, dan langkah verifikasi agar semua siap saat seri ini berlanjut.

#Skill Kubernetes yang Wajib Dikuasai

KEDA berjalan di dalam cluster sebagai operator. Semua objek yang dikelolanya adalah objek Kubernetes biasa, jadi skill di bawah ini bukan "sebaiknya", melainkan "wajib".

#Deployment, Service, dan Pod Scheduling

Kalian harus nyaman membaca dan menulis manifest Deployment, Service, ConfigMap, dan Secret. Yang terpenting, pahami pod scheduling: bagaimana Kubernetes memilih node untuk sebuah pod, apa itu nodeSelector, affinity, dan tolerations. Ini relevan karena episode 3 nanti kita akan bicara tentang menempatkan pod KEDA di node tertentu lewat tolerations.

#Namespace dan RBAC

Pahami Namespace sebagai batas isolasi resource, dan RBAC (Role, RoleBinding, ClusterRole, ClusterRoleBinding) sebagai sistem otorisasi Kubernetes. KEDA memakai RBAC untuk mengelola HPA milik kalian, dan episode 6 akan membahas otorisasi KEDA itu secara detail.

#Horizontal Pod Autoscaler (HPA)

HPA adalah fondasi paling dekat dengan KEDA. KEDA sebenarnya tidak menggantikan HPA — ia membuat dan mengelola HPA untuk kalian secara otomatis. Pastikan kalian paham cara kerja HPA, resource metrics (requests.cpu, requests.memory), dan cara memeriksanya:

Melihat HPA di cluster

kubectl get hpa
kubectl describe hpa my-deployment
kubectl get deploy -n keda

Khusus perintah kedua, HPA akan membaca metrik dari metrics-server. Tanpa metrics-server, kubectl top node dan autoscaling berbasis CPU akan gagal — kita akan memasangnya di bagian setup.

#Konsep Event-Driven Autoscaling

Ini bagian yang paling membedakan seri ini dari seri Kubernetes pada umumnya. KEDA hidup dari konsep bahwa ada sesuatu yang masuk ke sistem, dan jumlahnya tidak selalu sebanding dengan penggunaan CPU.

#Queue Depth dan Consumer Lag

Istilah pertama yang wajib kalian hafal adalah queue depth — jumlah pesan yang menunggu di dalam sebuah queue. Semakin tinggi queue depth, semakin banyak consumer yang dibutuhkan. Istilah kedua adalah consumer lag (khusus untuk stream seperti Kafka): selisih antara offset terakhir yang diproduksi dan offset terakhir yang dikonsumsi. Lag besar berarti konsumen kewalahan.

#Message Broker: Kafka, RabbitMQ, dan SQS

Kalian tidak perlu menjadi expert, tapi harus paham peran tiap broker karena KEDA punya scaler khusus untuk masing-masing:

#Prometheus Metrics

Prometheus adalah standar de facto untuk observability di ekosistem Kubernetes. Pahami konsep metric, label, dan query PromQL sederhana, karena episode-episode selanjutnya akan menulis query seperti sum(rate(http_requests_total[1m])) di dalam scaler Prometheus. Kalau sudah terbiasa dengan kubectl top node, bayangkan ini sebagai versi yang jauh lebih kaya dan bisa kalian buat sendiri.

#Tools dan Software yang Disiapkan

Untuk lab lokal, saya rekomendasikan kind untuk cluster yang cepat dibuat dan k3s jika ingin pengalaman yang lebih mendekati produksi. Semua valid — pilih yang paling nyaman dengan OS kalian.

#Setup Environment

#Membuat Cluster Lokal

kind create cluster --name keda-lab
kubectl config current-context
kubectl get nodes

#Memasang metrics-server

Di minikube, jalankan minikube addons enable metrics-server. Di cluster lain, install via Helm:

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade --install metrics-server metrics-server/metrics-server
kubectl get apiservices | grep metrics

Perhatikan pipa ke grep metrics — di dalam tabel, pipa semacam itu harus di-escape, misalnya `kubectl get apiservices \| grep metrics{:bash}`.

#Install KEDA

KEDA didistribusikan sebagai chart Helm resmi dari kedacore. Versi stabil terbaru saat tulisan ini dibuat adalah v2.20.2 (Juli 2026):

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda --namespace keda --create-namespace

#Verifikasi Setup

Sebelum lanjut ke episode 1, pastikan semuanya berjalan:

helm list -n keda
kubectl get pods -n keda
kubectl get crd | grep keda
kubectl top node

Output yang diharapkan: ada tiga Deployment aktif di namespace keda (keda-operator, keda-metrics-server, keda-admission-webhooks), beberapa CRD baru yang namanya diawali keda.sh, dan kubectl top node berhasil menampilkan metrik resource node.

#Penutup

Episode 0 adalah gerbang masuk seri ini. Berikut yang wajib kalian bawa:

• Kuasai Deployment, Service, Namespace, RBAC, dan HPA di Kubernetes.
• Pahami queue depth, consumer lag, dan peran broker seperti Kafka, RabbitMQ, dan SQS.
• Siapkan cluster, kubectl, Helm, dan metrics-server yang terverifikasi.
• Install KEDA v2.20.2 dan pastikan operator, metrics-server, dan webhook berjalan.

Di episode 1 kita mundur sejenak untuk menjawab pertanyaan paling mendasar: kenapa autoscaling berbasis CPU saja tidak cukup, bagaimana KEDA lahir pada 2019 dari Microsoft dan Red Hat, dan mengapa sampai menjadi proyek CNCF yang sudah graduated. Semua fondasi sudah siap — mari mulai!