Belajar KEDA - Production-Ready Deployment

#Pendahuluan

Di episode 20 sebelumnya kita menutup pemahaman tentang evolusi rilis: v2.20.2 stabil di Juli 2026, dan roadmap v3 sudah di depan mata. Namun versi terbaru saja belum cukup — produksi adalah cerita yang berbeda dari playground. Episode 21 ini menyatukan semuanya: arsitektur production-ready, GitOps untuk CRD, monitoring, dan lifecycle.

Istilah "production-ready" sering dianggap sekadar "pakai Helm chart resmi". Padahal itu baru langkah pertama. Episode ini mengupas tiga lapisan yang menentukan: bagaimana KEDA berinteraksi dengan HPA behavior dan Karpenter, bagaimana CRD hidup di alur GitOps tanpa bikin upgrade berantakan, dan bagaimana mengukur SLA workload event-driven.

#Arsitektur Production: Tiga Lapisan yang Saling Mengunci

#Lapisan Pertama: KEDA Mengelola HPA

Ingat kembali episode 2 dan 4: KEDA tidak menggantikan HPA, ia menjadi dalang di belakangnya. Operator KEDA membuat dan mengelola HPA dari setiap ScaledObject. Di produksi, inilah keuntungannya — kalian memanfaatkan mekanisme HPA yang sudah teruji, dengan kecerdasan trigger event-driven dari KEDA.

Yang sering luput: perilaku naik-turun HPA (behavior) bisa diatur langsung dari ScaledObject. Untuk workload queue, scale-up harus agresif dan scale-down harus hati-hati:

ScaledObject SQS dengan HPA behavior

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-consumer
spec:
  scaleTargetRef:
    name: sqs-consumer
  minReplicaCount: 1
  maxReplicaCount: 50
  pollingInterval: 15
  cooldownPeriod: 120
  triggers:
    - type: aws-sqs-queue
      authenticationRef:
        name: keda-trigger-auth-aws-credentials
      metadata:
        queueURL: https://sqs.ap-southeast-1.amazonaws.com/123456789012/orders
        queueLength: "5"
        awsRegion: ap-southeast-1
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 20
          periodSeconds: 60

stabilizationWindowSeconds: 0 pada scaleUp membuat respons terhadap lonjakan queue instan, sementara 300 detik pada scaleDown mencegah replika turun sebelum queue benar-benar kosong — dua angka yang berdampak langsung pada biaya dan ketersediaan (episode 15).

#Lapisan Kedua: Karpenter Menyediakan Node

KEDA menaikkan replika pod dari 0 ke 50 — tetapi pod itu harus menunggu node tersedia. Di sinilah Karpenter (episode 16) berperan: membaca pod pending dan memprovisikan node dalam hitungan detik. Kombinasi KEDA plus Karpenter adalah contoh klasik layered scaling: lapisan aplikasi dinaikkan KEDA, lapisan infrastruktur dinaikkan Karpenter. Untuk optimasi biaya, pasang kapasitas spot dan biarkan konsolidasi berjalan saat beban turun.

#Lapisan Ketiga: Verifikasi Hasil

Verifikasi hasilnya seperti biasa: kubectl get hpa -n production untuk melihat target saat ini, dan kubectl get nodes -l karpenter.sh/nodepool untuk melihat node yang diprovisikan Karpenter.

#GitOps untuk CRD KEDA

#Kenapa CRD Harus Masuk GitOps

CustomResourceDefinition (CRD) KEDA adalah salah satu resource paling sensitif terhadap urutan upgrade: kalau CRD diubah atau dihapus sebelum operator memahami versinya, ScaledObject bisa berhenti direkonsiliasi. Karena itu di produksi, CRD dan chart operator tidak boleh dikelola manual — keduanya hidup di Git.

Dengan ArgoCD, pola yang umum adalah App of Apps: satu Application untuk CRD dan satu untuk operator, disinkronkan berurutan lewat sync waves. Dengan Flux, cukup satu Kustomization. Prinsipnya sama seperti yang dipelajari di episode 3: kubectl apply -f untuk eksperimen, Git sebagai kebenaran untuk produksi.

Sync aplikasi GitOps

argocd app sync keda-crds --async
argocd app sync keda --async

Untuk Flux: flux reconcile kustomization keda-crds lalu flux reconcile kustomization keda. Aturan emasnya: CRD lebih dulu, operator menyusul — tanpa aturan ini, upgrade KEDA di produksi adalah undian.

#Pantau Kondisi Reconcile

Jangan tunggu error muncul dari user. Pantau status sync dan health setiap CRD: kubectl get scaledobject,scaledjob -A menampilkan apakah semuanya Ready dan Active. Pola ini persis troubleshooting episode 18, tetapi kini menjadi kebiasaan harian.

#Monitoring keda-operator

#Metrics yang Wajib Diobservasi

Operator dan metrics server KEDA mengekspos Prometheus metrics ber-prefix keda_scaler_. Setidaknya tiga yang wajib masuk dashboard: keda_scaler_metrics_value (nilai metrik per scaler), keda_scaler_errors_total (error saat mengambil metrik), dan keda_scaler_metrics_latency (seberapa lambat provider merespons).

Log operator juga menjadi sumber diagnosis utama: kubectl logs -n keda deploy/keda-operator --tail=50.

#Aturan Alert

sum(rate(keda_scaler_errors_total[5m])) by (namespace, scaledobject) > 0.1

#Lifecycle dan Skala

#Upgrade via Helm

Upgrade dengan Helm adalah operasi rutin yang tetap perlu prosedur: perbarui repo, lalu upgrade chart:

helm repo update kedacore
helm upgrade keda kedacore/keda --namespace keda --reuse-values
helm list -n keda
kubectl get pods -n keda -w

Gunakan --reuse-values hanya jika kalian tahu persis nilai yang sudah di-set; kalau ragu, evaluasi diff dulu dengan helm diff upgrade keda kedacore/keda -n keda (plugin diff). Selalu siapkan rollback plan: helm rollback keda 38 (ganti 38 dengan revisi sebelumnya).

#Versioning Scaler

Scaler bukan hanya kode — ia juga kontrak. Sebelum upgrade mayor, baca changelog untuk tiap scaler yang dipakai: parameter bisa berubah, API provider bisa deprecate. Buat matrix versi: versi KEDA, versi chart, dan daftar scaler beserta versi SDK provider-nya. Simpan matrix ini di Git bersama konfigurasi, bukan di kepala.

#Multi-Cluster

KEDA adalah kontroler per-cluster — tidak ada mode "central". Untuk banyak cluster, terapkan pola yang konsisten: satu repo Git dengan environment (staging, production), satu set CRD yang sama di semua cluster, dan observability yang digabung lewat satu Prometheus atau Thanos. Konsistensi inilah yang membuat multi-cluster terasa seperti satu platform.

#SLA untuk Workload Event-Driven

SLA workload event-driven jarang diukur dengan uptime semata — yang lebih relevan adalah latenci respons terhadap event. Contoh SLO yang masuk akal: 99% scale-up selesai dalam 60 detik sejak event masuk queue, dan nol kehilangan event karena autoscaling. Ukur lewat keda_scaler_metrics_latency, waktu pod ready, dan backlog queue.

Jika SLO ini terancam, prioritas perbaikannya sudah kalian pelajari: turunkan pollingInterval (episode 19), pastikan fallback (episode 11), dan jaga min replica untuk critical path (episode 15). Autoscaling yang baik adalah autoscaling yang terprediksi.

#Penutup

Episode ini menghubungkan semua elemen produksi: arsitektur tiga lapis KEDA, Karpenter, dan HPA behavior, GitOps dengan ArgoCD atau Flux dengan aturan CRD lebih dulu, monitoring operator lewat metrics keda_scaler_*, lifecycle upgrade dan versioning, serta SLA yang diukur dari latensi respons event.

Poin yang harus kalian bawa:

• Atur HPA behavior dari ScaledObject: scale-up agresif, scale-down hati-hati.
• CRD harus masuk GitOps; urutan upgrade: CRD lebih dulu, operator menyusul.
• Pantau keda_scaler_errors_total dan latency, bukan hanya status pod.
• Simpan matrix versi dan prosedur rollback untuk setiap upgrade.
• SLA event-driven diukur dari latensi, bukan sekadar uptime.

Ini episode kedua dari fase produksi. Episode 22 akan menutup seluruh seri: perbandingan ekosistem autoscaling (HPA murni, Prometheus adapter, KEDA, Knative), rekap 23 episode, dan arah evolusi KEDA v3. Sampai jumpa!