KEDA: Autoscaling Event-Driven & Scale-to-Zero di K8s

Kebanyakan saran autoscaling Kubernetes berhenti di Horizontal Pod Autoscaler yang memantau CPU. Itu cocok untuk layanan web yang CPU-nya naik seiring trafik, tetapi gagal untuk paruh sistem saya yang event-driven: worker yang menguras antrean RabbitMQ, consumer yang mengejar lag Kafka, batch job tengah malam. Pod-pod itu bisa mentok di CPU tinggi padahal backlog kosong, atau menganggur di CPU rendah padahal ribuan pesan menumpuk. CPU jelas sinyal yang keliru.

KEDA mengatasinya dengan menskalakan berdasarkan sumber event itu sendiri. KEDA lahir sebagai kolaborasi Microsoft dan Red Hat pada 2019, masuk CNCF Sandbox pada Maret 2020, pindah ke Incubator pada Agustus 2021, dan lulus sebagai proyek CNCF pada 22 Agustus 2023 — tingkat kematangan yang sama dengan Kubernetes sendiri. KEDA berjalan di produksi pada organisasi seperti FedEx, Grafana Labs, Reddit, dan Xbox, jadi ini bukan proyek coba-coba.

Mengapa CPU adalah sinyal yang keliru untuk kerja event-driven

HPA menjawab satu pertanyaan: apakah pod saya sibuk? Untuk API yang melayani request, itu proksi beban yang lumayan, karena lebih banyak request berarti lebih banyak CPU. Tetapi consumer antrean memisahkan kedatangan dari pemrosesan. Sepuluh ribu pesan bisa datang dalam satu ledakan sementara satu pod yang berjalan mengunyahnya pada CPU yang stabil dan biasa saja. HPA tidak melihat apa pun yang mengkhawatirkan dan tidak pernah scale out, sehingga backlog dan latensi Anda sama-sama naik sementara dashboard tampak tenang.

Yang sebenarnya Anda pedulikan adalah backlog, bukan CPU. Sinyal penskalaan yang tepat adalah kedalaman antrean, lag consumer Kafka, metrik Prometheus, atau bahkan jam. KEDA memungkinkan Anda menskalakan langsung berdasarkan angka-angka itu, dan dapat menahan deployment di nol replika saat tidak ada pekerjaan sama sekali — sesuatu yang tidak bisa dilakukan HPA biasa, karena lantainya adalah satu.

Bagaimana KEDA membungkus HPA alih-alih menggantikannya

KEDA tidak menulis ulang autoscaling; ia memperluas apa yang sudah dimiliki Kubernetes. Anda memasangnya sebagai operator, dan ia membagi tugas menjadi dua. Operator KEDA menangani tepi aktivasi — membawa deployment dari nol ke satu saat event pertama tiba, dan kembali dari satu ke nol saat sumber sepi. Segala hal di atas satu replika didelegasikan ke HPA standar yang dibuat dan dikelola KEDA untuk Anda.

Jembatannya adalah KEDA metrics API server, yang mengekspos angka yang di-polling dari sumber event Anda (Kafka, RabbitMQ, SQS, Prometheus, dan lainnya) sebagai external metrics Kubernetes. HPA yang dihasilkan membaca metrik itu persis seperti membaca CPU, lalu menskalakan satu-ke-N terhadap threshold Anda. Anda mendeskripsikan semua ini dalam satu custom resource, yaitu ScaledObject, dan KEDA menjaga HPA di baliknya tetap sinkron dengannya.

ScaledObject, dan menskalakan ke nol

Sebuah ScaledObject menunjuk workload yang akan diskalakan dan mendaftar satu atau lebih trigger. Dua field yang paling penting untuk biaya adalah minReplicaCount, yang default-nya nol dan itulah yang mengaktifkan scale-to-zero, serta maxReplicaCount, yang membatasi HPA di 100 secara default. KEDA memeriksa tiap trigger pada pollingInterval (30 detik secara default) dan, begitu sebuah sumber menganggur selama cooldownPeriod (300 detik secara default), menskalakan workload kembali ke nol.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: orders-consumer
  namespace: default
spec:
  scaleTargetRef:
    name: orders-consumer        # the Deployment to scale
  pollingInterval: 30            # check the trigger every 30s (default)
  cooldownPeriod: 300            # wait 300s idle before scaling to 0 (default)
  minReplicaCount: 0             # true scale-to-zero
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus.monitoring.svc:9090
        query: sum(rabbitmq_queue_messages_ready{queue="orders"})
        threshold: "50"           # target ~50 messages per replica
        activationThreshold: "5"  # only wake from 0 once 5+ messages queue

Field threshold adalah nilai target per replika: dengan threshold 50 dan 500 pesan menunggu, HPA membidik sekitar sepuluh replika. activationThreshold yang terpisah hanya mengontrol tepi nol-ke-satu — ia mencegah KEDA membangunkan seluruh deployment hanya untuk satu pesan nyasar, yang penting saat cold start mahal. Setel di atas nol untuk workload apa pun yang bangunnya tidak gratis.

Scaler: kedalaman antrean, lag Kafka, Prometheus, cron

Scaler adalah konektor yang membaca satu jenis sumber event. KEDA hadir dengan lebih dari 60 scaler bawaan saat lulus dan terus menambahnya, sehingga sebagian besar sumber umum tercakup langsung. Yang paling sering saya pakai:

• Antrean pesan — RabbitMQ, AWS SQS, Azure Service Bus, dan lainnya menskalakan berdasarkan jumlah pesan yang menunggu, sehingga replika mengikuti backlog nyata.
• Kafka — menskalakan berdasarkan lag consumer group, menambah pod saat group tertinggal dari partisinya dan menghapusnya begitu ia menyusul.
• Prometheus — scaler paling fleksibel: kueri PromQL apa pun menjadi sinyal penskalaan, sehingga Anda bisa menskalakan berdasarkan request per detik, latensi p95, atau metrik bisnis kustom.
• Cron — menskalakan ke jumlah replika tetap antara waktu mulai dan selesai dalam timezone tertentu, ideal untuk pre-warming sebelum puncak harian yang sudah diketahui dan kembali ke nol pada malam hari.

Trigger bisa digabung. Anda dapat menaruh trigger cron dan trigger Prometheus pada ScaledObject yang sama; KEDA mengambil jumlah replika tertinggi yang diminta trigger aktif mana pun. Kombinasi itulah cara saya menghangatkan layanan ke baseline sebelum kesibukan pagi dengan cron, sambil tetap membiarkan metrik langsung menskalakannya lebih jauh jika permintaan nyata melampaui perkiraan.

Trade-off cold-start yang tidak bisa Anda lewati

Scale-to-zero baru benar-benar hemat ketika waktu menganggur murah dan latensi tidak penting. Saat deployment berada di nol, event pertama tidak mendapat respons instan — ia harus menunggu polling interval KEDA agar terdeteksi, lalu pod harus dijadwalkan, image ditarik jika belum ter-cache, container dijalankan, dan readiness probe terpenuhi. Untuk runtime yang berat, itu bisa menambah latensi beberapa detik hingga puluhan detik pada request pertama setelah menganggur.

HPA berbasis CPU vs KEDA: apa bedanya

Aturan praktis saya: jika pekerjaannya menghadap pengguna dan terikat latensi, biarkan HPA menskalakannya berdasarkan CPU dan pertahankan lantai yang hangat. Jika pekerjaannya event-driven dan meledak-ledak — consumer antrean, pipeline Kafka, batch terjadwal — serahkan ke KEDA, pilih scaler yang cocok dengan sinyal nyata, dan biarkan turun ke nol di antara ledakan. Mulai dengan satu worker non-kritis, pasang satu trigger, dan amati ia bangun dan tidur sebelum Anda memercayakannya pada yang lebih sibuk.