Belajar KEDA - KEDA HTTP Add-on Deep Dive

#Pendahuluan

Di episode 11 kalian sudah menguasai fallback dan tuning lanjutan. Sekarang waktunya menyelam penuh ke add-on yang paling sering ditanyakan: KEDA HTTP Add-on. Di episode 9 kita sempat menyinggung HTTPScaledObject. Masalah intinya begini: workload HTTP biasanya tidak aman di-scale-to-zero, karena request yang datang saat nol pod langsung gagal. HTTP Add-on menjawabnya dengan menyisipkan lapisan interceptor di depan aplikasi — sekaligus membuka jalan untuk skema pending requests yang akurat. Sebelum menulis konfigurasi, penting memahami dulu siapa melakukan apa di dalam add-on ini.

#Arsitektur HTTP Add-on

Alur request dengan HTTP Add-on:

Alur request dengan HTTP Add-on

Client
  |  request masuk
  v
Ingress -> Interceptor (buffer saat replika 0)
               |
               +---> Deployment (pod aplikasi) setelah skala naik
               |
               +---> KEDA operator + HPA (membaca pending requests)

Tiga komponen yang bekerja sama:

• Interceptor: menangkap request, menahan (buffer) saat tidak ada pod, menghitung pending requests, lalu meneruskan request begitu pod siap.
• Operator add-on: mengelola HTTPScaledObject dan membuat interceptor beserta HPA terkait.
• Scaler HTTP: membaca jumlah request yang ditahan interceptor sebagai metrik scaling.

Komponen-komponen ini diinstall sebagai chart Helm terpisah, bukan bagian dari instalasi KEDA utama. Setelah terinstall, pastikan CRD-nya dikenali lewat kubectl get httpscaledobjects -n keda.

#Instalasi

helm repo add kedacore https://kedacore.github.io/charts
helm install keda-add-ons-http kedacore/keda-add-ons-http \
  --namespace keda --create-namespace
kubectl get pods -n keda -l app.kubernetes.io/name=keda-add-ons-http

Verifikasi bahwa interceptor, operator, dan scaler add-on muncul dalam kondisi Running sebelum membuat HTTPScaledObject.

#Konfigurasi HTTPScaledObject

HTTPScaledObject lengkap

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
metadata:
  name: web-app
  namespace: production
spec:
  hosts:
    - api.contoh.com
  scaleTargetRef:
    deployment: web-app
    service: web-app-svc
    port: 8080
  replicas:
    min: 0
    max: 10
    activation: 20
  scalingMetric:
    targetPendingRequests: 100
  cooldownPeriod: 300

Ketika request datang, interceptor menghitungnya sebagai pending. Jika melewati activation, add-on menaikkan pod. Pod baru dianggap siap setelah siap menerima request — baru pada saat itu request dibebaskan.

#Menangani Request Saat Scale-to-Zero

Selama tidak ada pod, interceptor tetap menerima koneksi dan menahan request di memori. Pahami bahwa interceptor adalah buffer, bukan storage: request yang ditahan terlalu lama akan dibatalkan oleh timeout. Untuk aplikasi dengan cold start lama, besarkan window scale-up dan kapasitas buffer.

#Batasan dan Catatan Produksi

Beberapa hal yang wajib kalian catat sebelum dipakai produksi:

• Kubernetes 1.30+: mekanisme penemuan endpoint interceptor berubah; versi add-on lama berbasis EndpointSlice tidak lagi kompatibel. Pastikan versi HTTP Add-on yang dipakai sudah memakai interceptor terbaru sebelum upgrade cluster.
• Satu deployment, satu HTTPScaledObject: jangan buat dua HTTPScaledObject untuk deployment yang sama, atau HPA akan saling berkonflik.
• TLS: terminasi TLS bisa dilakukan di Ingress, atau di interceptor lewat field tlsSecret pada scaleTargetRef.
• Banyak host: satu HTTPScaledObject mendukung banyak entry di hosts, cocok untuk routing beberapa domain ke workload yang sama.
• Resiliensi: pasang fallback (episode 11) dan pantau metrik pending requests serta keda_scaler_errors_total agar kegagalan add-on terdeteksi lebih awal.

#Penutup

• HTTP Add-on = interceptor (buffer request) + operator + scaler HTTP, diinstall sebagai chart terpisah.
• HTTPScaledObject mengatur hosts, deployment target, min/max/activation, dan targetPendingRequests.
• Saat scale-to-zero, interceptor menahan request hingga pod siap — tapi ia buffer, bukan storage.
• Atur kapasitas buffer dan timeout sesuai cold start aplikasi.
• Pantau metrik pending requests dan keda_scaler_errors_total untuk deteksi kegagalan lebih awal.
• K8s 1.30+ butuh versi interceptor baru; satu deployment hanya boleh punya satu HTTPScaledObject.

Workload sudah bisa diskalakan dan diamankan secara fungsional. Tapi ada satu sisi yang belum kita sentuh serius: keamanan kredensial. Di episode 13 kita membahas Security & Credentials — best practice secret management, podIdentity IRSA, Azure AD Workload Identity, GCP IAM, integrasi HashiCorp Vault, rotasi, dan kebijakan least privilege untuk akses queue dan stream dari operator KEDA. Sampai jumpa!