Belajar KEDA - Scalers Dasar

#Pendahuluan

Di episode 6, kalian sudah menguasai TriggerAuthentication — cara KEDA mendapat akses aman ke berbagai sistem eksternal. Sekarang saatnya membahas bagian yang paling sering dipakai setiap hari: trigger, atau sering disebut scaler. Di episode ini kita mengupas empat scaler dasar yang menjadi fondasi hampir semua workload event-driven: CPU/memory, cron, Prometheus, dan HTTP. Kenapa penting? Karena production nyata jarang cukup dengan satu jenis trigger — mereka menggabungkan sinyal resource, jadwal, dan metrik bisnis sekaligus dalam satu ScaledObject.

#Anatomi Trigger dalam ScaledObject

#Struktur Dasar

Setiap triggers di dalam spec ScaledObject adalah daftar yang berisi satu atau lebih trigger. Setiap trigger punya tiga bagian penting: type menentukan scaler mana yang dipakai, metadata berisi parameter spesifik scaler, dan authRef (opsional) menunjuk TriggerAuthentication untuk skenario ber-autentikasi.

Struktur umum triggers

spec:
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        query: sum(rate(http_requests_total[2m]))
        threshold: "100"

Semua nilai di metadata wajib berupa string — itulah mengapa kalian melihat threshold: "100" dengan tanda kutip, bukan angka 100 polos.

#Satu ScaledObject, Satu Workload

Aturan penting: satu Deployment hanya boleh dikelola satu ScaledObject. Kalau ingin menambah sinyal, tambahkan trigger baru di dalam ScaledObject yang sama. Jangan pernah membuat ScaledObject kedua untuk Deployment yang sama — hasilnya dua HPA berebut mengatur replika dan konflik.

#CPU & Memory Scaler

#Scaler CPU

Scaler CPU bekerja seperti HPA berbasis CPU, tapi terintegrasi dalam satu mekanisme dengan trigger lain. Ia cocok untuk workload yang responsif terhadap beban komputasi seperti API atau server web, dan memakai metrik yang sudah dikumpulkan metrics-server — tanpa kredensial eksternal apa pun.

ScaledObject CPU utilization

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-cpu
  namespace: production
spec:
  scaleTargetRef:
    name: api
  minReplicaCount: 1
  maxReplicaCount: 10
  cooldownPeriod: 120
  triggers:
    - type: cpu
      metricType: Utilization
      metadata:
        type: Utilization
        value: "60"

Di sini KEDA membangun HPA yang menjaga rata-rata utilisasi CPU seluruh pod pada 60 persen. Ketika utilisasi melewati angka itu, HPA menaikkan replika secara bertahap. Verifikasi hasilnya dengan kubectl get scaledobject api-cpu -n production dan kubectl get hpa -n production.

#Scaler Memory

Scaler memory identik, hanya metriknya diganti. Cocok untuk workload pemakan RAM besar, misalnya in-memory cache, data processing, atau worker yang mengumpulkan data sebelum memproses.

#Cron Scaler: Predictive Scaling

Berbeda dari semua scaler lain yang reaktif terhadap metrik, cron scaler bersifat prediktif: ia memaksa sejumlah replika pada jadwal tertentu, apa pun yang terjadi pada lalu lintas. Ini ideal untuk pola bisnis yang bisa diprediksi — promo jam 10 pagi, live streaming malam, atau batch laporan tengah malam.

Cron scaler zona waktu Indonesia

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: web-cron
spec:
  scaleTargetRef:
    name: web
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: cron
      metadata:
        timezone: Asia/Jakarta
        start: "30 8 * * *"
        end: "45 18 * * *"
        desiredReplicas: "5"

Antara pukul 08.30 dan 18.45 WIB setiap hari, KEDA menjaga 5 replika; di luar jadwal itu ia turun mengikuti metrik lain — di sini sampai nol karena minReplicaCount: 0. Pola ini dikenal sebagai predictive scaling atau schedule-based autoscaling.

#Prometheus Scaler: Query Kustom

Prometheus adalah mata KEDA untuk melihat metrik apa pun yang bisa dihitung. Dengan scaler ini kalian bebas mendefinisikan query — RPS, error rate, panjang antrean internal, hingga metrik bisnis — lalu KEDA menskalakan pod sesuai hasilnya.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-rps
spec:
  scaleTargetRef:
    name: api
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metricType: AverageValue
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        metricName: http_requests_rate
        query: |
          sum(rate(http_requests_total{job="api"}[2m]))
        threshold: "100"

Dengan metricType: AverageValue dan threshold: "100", satu pod dianggap cukup untuk menangani rata-rata 100 request per detik.

#HTTP Scaler: Pending Requests

Scaler http memantau berapa banyak request yang belum selesai diproses aplikasi — gabungan request in-flight dan yang mengantre. Ini sinyal latensi dan kemacetan yang jauh lebih halus daripada RPS: 100 request lambat lebih berbahaya daripada 1.000 request cepat.

HTTP scaler pending requests

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-http
spec:
  scaleTargetRef:
    name: api
  minReplicaCount: 0
  maxReplicaCount: 15
  triggers:
    - type: http
      metadata:
        pendingRequests: "10"
        targetPendingRequests: "10"
        requestTimeout: "3s"

Ketika pending requests melebihi 10, replika ditambah. Saat tidak ada request pending, pod bisa turun ke nol — aplikasi harus siap menerima cold start.

#Penutup

Empat scaler dasar sudah kalian kuasai:

• CPU/memory: metrik resource yang reaktif, cocok untuk workload komputasi, tanpa scale-to-zero.
• Cron: prediktif, memaksa replika sesuai jadwal, pas untuk pola bisnis yang bisa diprediksi.
• Prometheus: query kustom dari metrik apa pun, scaler paling fleksibel.
• HTTP: skala berdasarkan pending requests, sinyal kemacetan yang halus.

Empat sinyal ini masih mengukur metrik di dalam atau di sekitar cluster. Di episode 8 kita berangkat ke tempat KEDA paling sering dipakai di dunia nyata: message queue dan stream — dari AWS SQS dengan IRSA, Azure Service Bus, GCP Pub/Sub, hingga RabbitMQ, Kafka, Redis Streams, dan NATS JetStream. Sampai jumpa!