Learn KEDA - Custom Scalers & External Metrics

#Introduction

In episode 9 we got to know scalers for databases and HTTP. Even though KEDA has more than 70 scalers, the real world always has metrics that aren't covered — for example, internal system backlogs, your own SaaS metrics, or legacy mainframes. In this episode you'll learn two things: how KEDA talks to HPA through the External Metrics API, and how to build a gRPC custom scaler to connect internal systems to KEDA. Finally, we'll compose multi-triggers with precise AND/OR logic.

#How KEDA Talks to HPA: The External Metrics API

KEDA doesn't scale pods directly. The flow is layered: the scaler reads metrics from an external system, then the KEDA Metrics Server exposes the value through the External Metrics API, and the HPA that KEDA creates queries that API every synchronization cycle (usually 15 seconds) to determine the replica count.

This path is what makes KEDA compatible with standard Kubernetes HPA: KEDA simply acts as a metric source and manages the HPA's lifecycle. For the same reason, KEDA can't share a custom API server with other solutions in the same cluster.

#Building a gRPC Custom Scaler

#Core Concepts

If the 70+ built-in scalers still don't meet your needs, KEDA provides a gRPC-based external scaler interface. You write a gRPC server that implements the externalscaler protocol with three core methods:

IsActive — determines whether the system has events (used for scale-to-zero decisions).
GetMetricsSpec — tells KEDA the metric name and its target size.
GetMetricsAndReset — returns the latest metric values for HPA to compute.

#Implementing with the Go SDK

gRPC custom scaler skeleton

package main
 
import (
    "context"
    pb "github.com/kedacore/keda/v2/pkg/scalers/externalscaler"
)
 
type Scaler struct {
    pb.UnimplementedExternalScalerServer
}
 
func (s *Scaler) IsActive(ctx context.Context, req *pb.ScaledObjectRef) (*pb.IsActiveResponse, error) {
    n := countInternalBacklog()
    return &pb.IsActiveResponse{Result: n > 0}, nil
}
 
func (s *Scaler) GetMetricsSpec(ctx context.Context, req *pb.ScaledObjectRef) (*pb.GetMetricsSpecResponse, error) {
    return &pb.GetMetricsSpecResponse{
        MetricSpecs: []*pb.MetricSpec{{
            MetricName: "internal-backlog",
            TargetSize: 100,
        }},
    }, nil
}
 
func (s *Scaler) GetMetricsAndReset(ctx context.Context, req *pb.GetMetricsRequest) (*pb.GetMetricsResponse, error) {
    return &pb.GetMetricsResponse{
        MetricValues: []*pb.MetricValue{{
            MetricName:  "internal-backlog",
            MetricValue: countInternalBacklog(),
        }},
    }, nil
}

This gRPC server runs as a separate Deployment inside the cluster, then gets connected to KEDA through the gRPCConfig block. Note countInternalBacklog — replace it with real logic that reads your internal system.

#Registering It in a ScaledObject

KEDA reaches the gRPC server via the gRPCConfig configuration, and forwards the metadata written in the ScaledObject as trigger parameters.

Tip

Enable useCachedClients: true so the operator doesn't create a new gRPC connection for each poll — the connection is opened once and then reused. If your internal scaler needs TLS, add the certificate in the gRPCConfig block.

#Multi-Trigger in a Single ScaledObject

KEDA combines several triggers in one ScaledObject with two important rules.

Metric values are summed: the value reported to HPA is the sum of all triggers. This behaves like "OR" — a single large trigger is enough to push scale-up.
Scale-to-zero requires all triggers inactive: like "AND" — pods only drop to zero if every trigger is inactive. A single active trigger is enough to keep at least one replica.

#Precise AND/OR Logic: scalingModifiers

Because summation doesn't always fit your needs, KEDA v2.20 provides scalingModifiers with expression formulas — including the ternary operator for precise AND/OR logic.

The max(trig_a, trig_b) formula makes KEDA use the highest value of the two triggers — pure OR logic. For AND, use min(...). Other combinations such as trig_a + trig_b or the ternary trig_a > 2 ? trig_a + trig_b : 1 can also be written directly.

Warning

When combining triggers, pay attention to the metric scale. Combining a trigger in the thousands with a trigger in the single digits through summation will make the small trigger invisible. Normalize the values or use max/min via scalingModifiers.

#Conclusion

KEDA talks to HPA through the External Metrics API: kubectl get --raw /apis/external.metrics.k8s.io/v1beta1.
A custom scaler is a gRPC server that implements IsActive, GetMetricsSpec, and GetMetricsAndReset.
Register the custom scaler via gRPCConfig and metadata in the ScaledObject.
Multi-trigger default: values are summed (OR effect); scale-to-zero requires all triggers inactive (AND effect).
scalingModifiers with formulas gives precise AND/OR control for complex needs.

Your scalers can now be anything — but what happens when a scaler fails to read metrics? In episode 11 we discuss fallback and advanced config: keeping minimum availability when a scaler errors, and setting pollingInterval, cooldownPeriod, restoreToOriginalReplicaCount, HPA behavior, and scalingStrategy. See you there!