KEDA

The KubeMQ KEDA external scaler brings Kubernetes-native autoscaling to KubeMQ queue consumers. It is a standalone gRPC service that reads the live Waiting message count from a KubeMQ queue channel and exposes it to KEDA as a single metric, so a ScaledObject can scale queue-consuming workloads — GPU inference workers, batch processors, task consumers — up and down (and all the way to zero) on real backlog rather than CPU or memory.

What it is

KEDA is the Kubernetes Event-Driven Autoscaler. It scales workloads from external signals through scalers — small gRPC services that implement KEDA's ExternalScaler interface. The KubeMQ scaler is one such service: it answers KEDA's IsActive / GetMetrics calls by querying the broker's ListQueuesChannels API and reporting the channel's Outgoing.Waiting count.

Unlike the framework adapters in this section, KEDA is not a messaging client your app embeds — it is an autoscaler that runs alongside your consumers. Your consumers connect to KubeMQ with the native gRPC SDK on port 50000 as usual; the scaler observes the same queues over that API and tells KEDA how many replicas to run. The metric it exposes is queue depth, so the underlying concept is Queues — the scaler reads the same Waiting count you would see when introspecting a queue channel.

Why KEDA + KubeMQ

• Queue-depth-driven autoscaling — scale on the live Waiting count of a queue, not on CPU or memory.
• Scale-to-zero — drop a deployment to zero replicas when its queue is empty and scale back up the moment work arrives.
• Never-fake-zero — KubeMQ errors map to gRPC status codes so KEDA applies its fallback strategy on a broker outage instead of scaling a healthy workload to zero.
• Push or poll — external (poll) and external-push (long-lived stream) trigger types, the latter for faster scale-from-zero detection.
• Lightweight — a single Go service requesting just 50m CPU and 64Mi memory, hardened with a non-root, read-only-root-filesystem securityContext.

Architecture

The scaler is a standalone gRPC ExternalScaler server (default port 9090). The KEDA operator calls it to read queue depth; the scaler in turn dials the KubeMQ broker's gRPC API (50000), calls ListQueuesChannels, and reports the Waiting count so KEDA can scale the target deployment.

The KEDA operator reads queue depth from the scaler, which polls the KubeMQ broker and drives the target deployment's replica count.

The metric and the RPCs

The scaler exposes exactly one metric, kubemq-queue-waiting, whose value is the queue channel's Outgoing.Waiting count. It implements the four RPCs of KEDA's ExternalScaler service:

KEDA supports two trigger types against the same scaler — external (poll-based, default) and external-push (a long-lived StreamIsActive stream for faster scale-from-zero). See Concepts for the full model.

Prerequisites

• Kubernetes 1.27+ — required for the native gRPC liveness/readiness probes the scaler uses.
• KEDA 2.10+ — installed in the cluster.
• A KubeMQ broker — reachable in-cluster on its gRPC port 50000 at the address you pass in kubemqAddress.

Supported runtime

The scaler is a standalone Go service, not a language SDK you embed — your consumers can be written in any language and connect to the broker over native gRPC as usual.

A ScaledObject at a glance

A ScaledObject targets your consumer Deployment and points an external trigger at both the scaler Service and your broker:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kubemq-queue-scaler
spec:
  scaleTargetRef:
    name: my-queue-consumer
  pollingInterval: 15
  cooldownPeriod: 60
  minReplicaCount: 1
  maxReplicaCount: 10
  triggers:
    - type: external
      metadata:
        scalerAddress: kubemq-keda-scaler.default.svc.cluster.local:9090
        kubemqAddress: kubemq.default.svc.cluster.local:50000
        queueName: my-queue
        targetWaiting: "10"

Explore

New to integrations? See what an integration is for the mental model, then the Queues concept and the Getting Started guide for the core SDK your consumers use. The scaler observes queues over native gRPC on port 50000 — it is not a connector.