Belajar KEDA - Scale-to-Zero & Activation

#Pendahuluan

Di episode 4 kita berkenalan dengan minReplicaCount: 0 — fitur yang paling sering membuat orang tertarik pada KEDA. Episode 5 mengupasnya sampai habis: apa yang sebenarnya terjadi ketika replika menjadi nol, mengapa ini menghemat biaya, tapi juga kapan ini menjadi keputusan yang buruk.

Spoiler: scale-to-zero bukan fitur gratis. Ia adalah trade-off antara biaya dan latensi, dan episode ini akan memberi kerangka berpikir untuk mengambil keputusan itu secara sadar.

#Apa yang Terjadi Saat Scale-to-Zero

Ketika minReplicaCount: 0 dan tidak ada event, KEDA menyetel HPA ke nol replika. Pod dihapus, dan Deployment tidak punya pod sama sekali. Ini berbeda dari mematikan deployment — workload tetap terdaftar dan siap "dibangunkan" begitu metrik melewati ambang.

ScaledObject dengan minReplicaCount nol

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-worker-scaledobject
spec:
  scaleTargetRef:
    name: order-worker
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        queueLength: "20"

Memeriksa replika setelah scale-to-zero

kubectl get deploy order-worker
kubectl get hpa order-worker-scaledobject
kubectl get pods -l app=order-worker

Perintah ketiga akan menampilkan daftar pod kosong, sementara HPA tetap ada dan aktif memantau metrik. Untuk workload yang menganggur berjam-jam — worker malam, batch report, AI inference jarang — ini artinya tidak ada biaya compute untuk waktu idle, yang bisa berarti hemat 40-60 persen dari tagihan bulanan. Kalau ingin melihat detail statusnya, baca objeknya langsung: kubectl get scaledobject order-worker-scaledobject -o yaml.

#Kapan Aman dan Kapan Berbahaya

Scale-to-zero punya biaya tersembunyi: cold start. Ketika event pertama masuk, harus ada pod baru yang dibuat, image ditarik, dan container dijalankan. Selama rentang itu, pesan menunggu di queue.

#Aman untuk Workload yang Toleran Terhadap Latensi

Scale-to-zero aman jika workload kalian tidak peka terhadap latensi: batch processing di malam hari, ETL terjadwal, analisis data. Satu menit menunggu pod hidup tidak masalah karena yang penting pesan akhirnya diproses.

#Berbahaya untuk Alur yang Sensitif Latensi

Berbahaya jika prosesnya berinteraksi langsung dengan user atau downstream yang menunggu respons cepat — misalnya worker yang menangani request HTTP, atau consumer yang harus mempertahankan consumer lag di bawah ambang tertentu. Untuk kasus ini, jangan pakai nol:

Menjaga replika minimum demi latensi

spec:
  scaleTargetRef:
    name: web-worker
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring:9090
        query: sum(rate(worker_processed_total[2m]))
        threshold: "10"

#idleReplicaCount: Kompromi Cerdas

Jika scale-to-zero terlalu agresif tapi biaya tetap jadi perhatian, gunakan idleReplicaCount. KEDA menurunkan replika ke nilai idle saat tidak ada event — pod tetap ada (siap bangun cepat) tapi dengan biaya minimal:

Menggunakan idleReplicaCount sebagai kompromi

spec:
  scaleTargetRef:
    name: order-worker
  minReplicaCount: 0
  maxReplicaCount: 10
  idleReplicaCount: 1
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        queueLength: "20"

Dengan konfigurasi ini, replika turun ke 1 (bukan 0) saat idle — trade-off yang baik antara biaya dan kecepatan bangun.

#activationThreshold: Mencegah Flapping

Masalah yang sering muncul dengan minReplicaCount: 0 adalah flapping: event kecil sekali-sekali menyebabkan KEDA membangunkan pod yang langsung mati lagi. Setiap bangun-tidur itu punya biaya — pod ditarik, dijadwalkan, dibayar untuk beberapa detik.

Solusinya adalah activationThreshold. Metrik harus melewati nilai ini sebelum KEDA mulai menskalakan dari nol. Contoh: queue RabbitMQ dengan queueLength: 20 dan activationThreshold: 10 berarti KEDA baru membangunkan pod jika ada lebih dari 10 pesan menunggu — satu-dua pesan sementara tidak akan memicu apa-apa.

activationThreshold untuk queue

spec:
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        queueLength: "20"
        activationThreshold: "10"

#Menyesuaikan Sensitivitas

Ada tiga tombol yang bisa kalian putar untuk mengontrol seberapa "mudah" KEDA bangun:

• activationThreshold: seberapa tinggi metrik sebelum scale-up dari nol.
• pollingInterval: seberapa sering KEDA memeriksa (kecil = lebih responsif, besar = lebih hemat API).
• cooldownPeriod: berapa lama menunggu sebelum menurunkan replika (besar = kurang flapping, tapi membiarkan pod menganggur lebih lama).

#Penutup

Episode 5 membuat scale-to-zero bisa dipakai dengan aman. Berikut yang wajib kalian bawa:

• minReplicaCount: 0 menghemat idle compute 40-60 persen untuk workload batch.
• Hindari scale-to-zero untuk workload yang peka latensi; idleReplicaCount adalah kompromi.
• Waspadai cold start dan pola long-poll saat pod mati.
• activationThreshold mencegah flapping dengan menunda scale-up dari nol.

Di episode 6 kita membahas bagian yang sering bikin orang tersandung saat scaler sudah diatur: autentikasi. TriggerAuthentication dan ClusterTriggerAuthentication, dari secretTargetRef hingga podIdentity di AWS, Azure, dan GCP.