Belajar KEDA - Advanced Scalers & Ekosistem

#Pendahuluan

Di episode 16 kita melihat KEDA berdampingan dengan Karpenter untuk menskalakan node. Sampai titik ini, contoh kita berkisar pada SQS dan Redis — tapi KEDA punya lebih dari 70 scaler, dan banyak yang berjalan di luar pola queue klasik. Episode ini membahas Advanced Scalers & Ekosistem: scaler yang berinteraksi dengan API eksternal, event push, hingga bagaimana KEDA dipasangkan dengan Argo Rollouts, Knative, dan service mesh. Setelah ini, pola pikir kalian tentang "apa yang bisa menskalakan apa" akan melebar drastis.

#GitHub Scaler

Scaler GitHub memungkinkan autoscaling berdasarkan aktivitas GitHub — bukan queue. Contoh nyata: menskalakan runner pipeline atau bot pemberi label (labeling bot) berdasarkan sisa API rate limit atau jumlah issue yang belum terselesaikan. KEDA membaca GitHub API dengan token pribadi:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: github-triage-bot
spec:
  scaleTargetRef:
    name: triage-bot
  maxReplicaCount: 5
  triggers:
    - type: github
      metadata:
        owner: devnull
        repository: devvnull.vercel.app
        query: "is:issue is:open"
      authenticationRef:
        name: github-token

Metrik yang dihitung KEDA dari query di atas adalah jumlah issue terbuka. Triage bot naik saat issue menumpuk, lalu turun ke nol saat antrean triage bersih. Kasus lain yang populer: query berbasis rate limit — bot berhenti menskalakan saat github.rate_limit.remaining mendekati nol, mencegah API di-throttle.

#Azure Storage Queue & GCP Cloud Storage

Di episode 8 kita membahas SQS. Dua analog cloud lain menggunakan skema serupa dengan credential provider masing-masing.

#Azure Storage Queue

scaledobject-azure-queue.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-worker
spec:
  scaleTargetRef:
    name: azure-worker
  maxReplicaCount: 30
  triggers:
    - type: azure-queue
      metadata:
        queueName: jobs
        queueLength: "10"
        connectionFromEnv: AZURE_STORAGE_CONNECTION_STRING

Autentikasi bisa memakai connection string dari env, atau podIdentity dengan workload identity Azure.

#GCP Cloud Storage

Scaler GCP Cloud Storage bekerja berdasarkan jumlah object di sebuah bucket atau folder tertentu:

scaledobject-gcs.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gcs-processor
spec:
  scaleTargetRef:
    name: gcs-processor
  maxReplicaCount: 20
  triggers:
    - type: gcp-storage
      metadata:
        bucketName: ingest-bucket
        prefix: "raw/"
        count: "10"

KEDA menghitung object di raw/; saat melebihi 10, replika gcs-processor bertambah. Ini pola khas data pipeline: file mendarat, worker memproses, file dihapus, replika turun — biaya compute hanya ada saat ada data.

#External Push & Scalers Komunitas

Beberapa event tidak bisa dipolling efisien — seperti message broker yang perlu push, atau sistem internal dengan API khusus. KEDA menyediakan dua jalan:

• external-push scaler: workload di-scale-up oleh pemicu eksternal via push gRPC ke KEDA — ideal untuk event yang datang jarang tapi harus cepat, menghindari polling mahal. Untuk sistem internal, gunakan external scaler gRPC kustom (bahasan mendalam di episode 10).
• Scalers komunitas: dikelola di luar repo inti kedacore/keda, misal scaler untuk Jenkins, Bitbucket, atau tool observability tertentu. Selalu periksa maturity dan dukungannya sebelum dipakai di production — scaler komunitas tidak mendapat jaminan yang sama dengan scaler resmi.

#KEDA + Argo Rollouts

KEDA berpasangan alami dengan Argo Rollouts untuk deployment canary dan blue-green yang sadar metrik. Argo Rollouts menggeser traffic bertahap ke versi baru; analisisnya bisa memakai metrik KEDA. Inilah kombinasi yang membuat penilaian deployment berbasis kualitas — bukan sekadar "pods ready".

rollout-with-analysis.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout-service
spec:
  strategy:
    canary:
      steps:
        - setWeight: 25
        - analysis:
            templates:
              - templateName: error-rate
  selector:
    matchLabels:
      app: checkout-service
  template:
    metadata:
      labels:
        app: checkout-service
    spec:
      containers:
        - name: checkout
          image: ghcr.io/devnull/checkout:v2

Analysis template memakai metrik Prometheus yang bisa berasal dari scaler KEDA:

analysis-error-rate.yaml

apiVersion: argoproj.io/v1beta1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
    - name: error-rate
      prometheus:
        address: http://prometheus.monitoring:9090
        query: sum(rate(http_requests_total{status="5xx"}[5m]))

Saat error rate melewati batas, Rollout membatalkan canary dan mengembalikan traffic ke versi lama. KEDA mengautoscale pods; Argo Rollouts mengatur release.

#KEDA + Knative: Scale-from-Zero Dua Sekolah

Knative Serving punya autoscaler sendiri yang menskalakan Revision dari nol berdasarkan concurrency dan request. KEDA dan Knative sama-sama bisa scale-to-zero, tetapi dengan filosofi berbeda:

Keduanya komplementer: gunakan Knative untuk API request-driven yang butuh scale-from-zero dengan routing traffic otomatis, dan KEDA untuk worker yang dipicu backlog. Saat Knative menggunakan activator untuk buffer request selama scale-to-zero, KEDA HTTP Add-on menggunakan interceptor untuk peran yang sama.

#Integrasi Service Mesh

Dengan service mesh (Istio/Linkerd), KEDA tetap bekerja di lapisan Deployment — tidak peduli bagaimana traffic di-route. Yang perlu diperhatikan:

• Istio sidecar menambah waktu cold start pod baru; saat scale-up dari nol, pastikan budget termasuk init container readiness.
• Pola adaptive concurrency limit (ACL) dari service mesh justru dipasangkan dengan metrik yang dimakan KEDA: KEDA menskalakan replika, mesh mengatur concurrency per replika.
• Scaler HTTP KEDA bisa membaca metrik request dari mesh (Istio istio_requests_total) sebagai pemicu — pengganti interceptor saat seluruh traffic melewati mesh.

#Kesalahan Umum

1. Memakai scaler komunitas tanpa meninjau kode. Di produksi, pilih scaler resmi atau yang dikelola organisasi kalian sendiri.
2. GitHub token tanpa scope repo. Scaler GitHub gagal dengan 403 saat token tidak punya hak baca — uji dengan curl -s https://api.github.com/rate_limit sebelum membuat ScaledObject.
3. Lupa prefix di GCP Storage. Tanpa prefix, KEDA menghitung seluruh object bucket — scale-up mendadak di luar dugaan.
4. Memadukan Rollout dan HPA biasa ke Deployment sama. Argo Rollouts menganjurkan memakai KEDA/analysis daripada HPA klasik agar versi baru tidak ikut di-scale oleh metrik lama.
5. Knative dan KEDA di Deployment sama. Pilih salah satu pemilik scaling pada satu Deployment untuk menghindari dua controller berebut replika.

#Penutup

Episode ini melebarkan cakrawala scaler: GitHub untuk aktivitas repo, Azure Storage Queue dan GCP Cloud Storage untuk pipeline data cloud, external-push untuk event yang tidak bisa dipolling, serta scaler komunitas yang perlu ditinjau hati-hati. Di lapisan ekosistem, KEDA berdampingan dengan Argo Rollouts untuk canary sadar metrik, Knative untuk scale-from-zero HTTP, dan service mesh untuk kontrol concurrency.

Poin yang harus kalian bawa:

• Scaler GitHub bisa memicu autoscaling dari rate limit atau jumlah issue.
• Azure Queue dan GCS memakai pola autentikasi yang sama dengan scaler cloud lain.
• external-push untuk event jarang tapi harus cepat, external scaler untuk sistem internal.
• Argo Rollouts menilai kualitas rilis; KEDA mengatur jumlah replika.
• Knative dan KEDA punya filosofi scale-to-zero berbeda — pilih sesuai jenis workload.

Dari sekian banyak scaler dan integrasi, saat sesuatu gagal di produksi kalian harus tahu caranya memeriksa. Di episode 18 selanjutnya kita membahas Troubleshooting & Monitoring: diagnosa ScaledObject dengan kubectl, membaca log operator, memanfaatkan metrik keda_scaler_*, dan menyelesaikan masalah umum seperti status Unknown, HPA tak ter-update, hingga webhook error. Sampai jumpa di episode 18!