Belajar KEDA - Setup & Instalasi

#Pendahuluan

Di episode 2 kita sudah memetakan arsitektur KEDA: operator, metrics server, dan admission webhooks. Sekarang saatnya benar-benar menurunkannya ke cluster kalian. Di episode 0 kita sempat menjalankan perintah install singkat; episode 3 ini melengkapinya: apa yang sebenarnya terinstall, bagaimana memverifikasinya, bagaimana menyesuaikan instalasi untuk kebutuhan produksi, dan alternatif jika kalian tidak ingin memakai Helm.

#Instalasi dengan Helm

Helm adalah cara resmi dan paling umum untuk menginstall KEDA. Chart resmi berada di repository kedacore:

Menambahkan repository dan install KEDA

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

Tip

Meskipun install default langsung berjalan, selalu tentukan namespace eksplisit seperti di atas. Menginstall ke namespace keda membuat objek KEDA mudah ditemukan dan diisolasi saat kita perlu membersihkannya nanti.

#Verifikasi Instalasi

Setelah beberapa saat, pastikan ketiga Deployment aktif dan siap:

Dari perintah kedua, kalian akan melihat tiga deployment: keda-operator, keda-metrics-server, dan keda-admission-webhooks. Jika ketiganya Ready 1/1, instalasi sukses dan kalian bisa lanjut. Periksa kembali dengan kubectl get deploy -n keda setiap kali ada yang terasa aneh. Untuk instalasi versi spesifik, gunakan flag --version:

Install versi tertentu dan periksa status release

helm upgrade keda kedacore/keda --namespace keda --version 2.20.2
helm list -n keda

#Opsi Konfigurasi via `--set`

Chart KEDA sangat fleksibel lewat --set. Beberapa opsi yang paling sering dipakai:

Contoh kustomisasi instalasi

helm upgrade keda kedacore/keda --namespace keda \
  --set image.pullPolicy=IfNotPresent \
  --set podIdentity.activeDirectory.operator.identity=keda-operator-id \
  --set operator.replicas=2

Opsi-opsi umum yang perlu kalian kenal: operator.replicas untuk HA, metricsServer.replicas untuk metrik yang selalu tersedia, dan podDisruptionBudget untuk menjaga ketersediaan selama maintenance. Dokumentasi chart kedacore/keda di GitHub mencantumkan seluruh nilai yang bisa di-set.

#Tolerations dan Resources

Untuk cluster dengan node taint (misal node khusus untuk platform tooling), KEDA bisa dipaksa menempati node tertentu:

Mengatur tolerations dan resource limits

helm upgrade keda kedacore/keda --namespace keda \
  --set tolerations[0].key=platform \
  --set tolerations[0].operator=Exists \
  --set operator.resources.requests.cpu=100m \
  --set operator.resources.limits.memory=512Mi

Perhatikan bahwa nilai tolerations ditulis sebagai array di dalam satu perintah; untuk konfigurasi yang kompleks, lebih baik simpan sebagai values.yaml terpisah agar mudah di-review dan masuk akal untuk versi kontrol.

#Alternatif: YAML Manifest untuk GitOps

Tidak semua orang menyukai Helm di dalam pipeline GitOps. KEDA juga menerbitkan manifest YAML kustom yang bisa di-apply langsung — cocok untuk alur ArgoCD atau Flux di mana semua sumber deploy adalah file YAML murni.

Install KEDA dari manifest kustom

kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.20.2/keda-2.20.2.yaml
kubectl get pods -n keda

Versi manifest selalu mengikuti tag rilis di GitHub kedacore/keda. Dengan pola ini, kalian bisa menaruh file manifest di repository dan membiarkan ArgoCD yang menyinkronkannya — tidak ada state Helm yang perlu dijaga.

Warning

Jika kalian beralih dari Helm ke manifest (atau sebaliknya), jangan sampai keduanya mengelola objek yang sama. Objek yang dibuat Helm punya label app.kubernetes.io/managed-by=Helm; menghapus release Helm akan menghapus seluruh objeknya, termasuk yang mungkin sudah kalian modifikasi manual.

#Add-on Cloud: AKS dan EKS

Untuk pengguna cluster terkelola, KEDA juga tersedia sebagai add-on native:

AKS: aktifkan add-on keda via Azure CLI atau portal. KEDA berjalan sebagai extension terkelola — upgrade versi ditangani Azure.
EKS: tidak ada add-on KEDA bawaan, tetapi instalasi via Helm di atas jalan mulus di EKS. Banyak tim mengombinasikannya dengan eksctl untuk provisioning cluster dan Helm untuk install KEDA.

Mengaktifkan KEDA add-on di AKS

az aks update --resource-group my-rg --name my-cluster \
  --enable-keda

Add-on terkelola mengurangi beban operasional, tetapi memberi kontrol lebih sedikit atas opsi --set. Pilih berdasarkan seberapa besar kebutuhan kustomisasi kalian.

#Upgrade, Rollback, dan Uninstall

Merawat KEDA sama pentingnya dengan menginstallnya. Ada tiga operasi yang pasti kalian butuhkan suatu saat.

#Upgrade ke Versi Terbaru

Selalu mulai dengan helm repo update agar metadata chart segar, lalu upgrade:

Upgrade KEDA ke versi terbaru

helm repo update
helm upgrade keda kedacore/keda --namespace keda --version 2.20.2
kubectl get pods -n keda -w

#Rollback

Jika sebuah upgrade menyebabkan masalah, Helm menyimpan histori release. Cek riwayat dengan helm history keda -n keda, lalu kembali ke rilis sebelumnya:

Rollback ke rilis sebelumnya

helm history keda -n keda
helm rollback keda 1 --namespace keda

#Uninstall

Menghapus KEDA dari cluster

helm uninstall keda --namespace keda

Warning

Sebelum uninstall, pastikan tidak ada ScaledObject atau ScaledJob yang masih dipakai — HPA buatan KEDA akan ikut terhapus dan workload berhenti diskalakan. Perlu diketahui: Helm 3 tidak menghapus CRD saat uninstall, jadi CRD keda.sh akan tertinggal di cluster dan bisa dihapus manual jika benar-benar ingin membersihkan semuanya.

#Penutup

Episode 3 membuat KEDA benar-benar berjalan di cluster. Berikut yang wajib kalian bawa:

Install via helm install keda kedacore/keda --namespace keda --create-namespace.
Verifikasi tiga deployment: operator, metrics server, dan admission webhooks.
Kustomisasi lewat --set untuk tolerations, resources, dan HA.
Alternatif manifest YAML untuk alur GitOps, plus add-on terkelola di AKS/EKS.

Di episode 4 kita masuk ke objek yang paling sering kalian tulis: ScaledObject untuk workload berkelanjutan dan ScaledJob untuk batch — termasuk seluruh field kuncinya dan perbedaan perilaku keduanya.