KEDA Event Autoscaling: Triggers, Zero, and Failures

KEDA

KEDA connects event-source signals to Kubernetes workload scaling. Use it when worker demand is better expressed by a queue or another supported event metric than by CPU alone. First define what the metric counts, how workers finish work, and what should happen when the metric cannot be read.

More replicas cannot repair a broken broker credential or a job that fails forever. Autoscaling is a capacity response inside a larger processing system.

TL;DR

A ScaledObject connects a scalable workload to one or more event triggers.
KEDA activation and HPA replica adjustment are separate parts of the scaling path.
Choose queue semantics, activation thresholds, and replica limits explicitly.
Reference credentials through suitable authentication resources and protect their scope.
Treat failed metric collection differently from a confirmed empty queue.
Test startup delay, in-flight work, termination, retries, and downstream limits before enabling scale to zero.

Quick Example

This KEDA 2.21 example targets an existing worker Deployment in an existing jobs namespace. It assumes a reachable RabbitMQ broker, an existing jobs queue, installed KEDA controllers/CRDs, and a rabbitmq-connection Secret containing a uri key in the same namespace. Provision a scoped TLS amqps:// connection through your approved secret workflow; no credentials belong in this file.

This is configuration for a controlled nonproduction pilot, not a standalone cluster installation. Parse and review it before applying it to an authorized environment. The RabbitMQ scaler reference documents mode, value, activationValue, and connection parameters; the older queueLength setting is deprecated. Local parsing does not validate credentials, broker permissions, CRD admission, or actual controller behavior.

For a fictional backlog of 95 messages and a target of 20 per worker, a simple capacity estimate is ceil(95 / 20) = 5. At 250 messages, that estimate exceeds the example's cap of 10. This arithmetic illustrates a target; it is not an exact simulation of HPA timing, tolerances, current metrics, or ready capacity.

Core Concepts

Activation is different from ordinary scaling

KEDA handles the zero-to-active transition; the HPA handles adjustments among active replica counts. Activation uses its own threshold, with the metric needing to exceed it. A positive minimum means the workload stays active. The deployment-scaling concepts explain this division. If your latency budget cannot tolerate polling plus startup time, keeping a minimum worker available may be the better tradeoff.

Cooldown is not the entire scale-down policy

cooldownPeriod governs KEDA's return to zero after inactivity. It is not a universal delay for every reduction from ten replicas to five. Active-replica behavior belongs to the HPA configuration and current Kubernetes behavior. Consult the ScaledObject specification when tuning polling, minimums, maximums, and advanced settings.

Authentication is a separate operating dependency

The worker's ability to consume a queue and the scaler's ability to inspect it are separate checks. A running worker does not prove that KEDA can obtain its metric. Namespace-scoped TriggerAuthentication resources are referenced by same-namespace ScaledObject resources; KEDA authentication guidance also describes cluster-scoped alternatives. Avoid expanding credential access merely to simplify a manifest.

Design Around the Processing Failure

The example deliberately uses AMQP queue-length scaling, which excludes unacknowledged messages. Use the HTTP protocol when the scaling signal must include that in-flight work. Inspect the selected protocol's actual counting semantics before treating the signal as all outstanding work. RabbitMQ's HTTP-based options include different handling of unacknowledged messages; do not silently carry one protocol's assumptions into another.

Plan worker shutdown independently. A worker may hold a message when its Pod is terminated. Your proposed acceptance test should verify acknowledgments, redelivery, idempotent side effects, and sufficient graceful termination time under the real workload. A successful drain once does not eliminate duplicate delivery as a design concern.

Metric loss is an especially useful negative test. Record the ScaledObject conditions, generated HPA status, events, and operator diagnostics. If considering KEDA fallback behavior, check the chosen scaler and metric-type support in the installed version. A fallback configuration is not proof that an inactive workload will recover from every source or authentication failure.

Best Practices

Derive targets from observed work

Choose a queue-per-worker target from processing time, concurrency, and latency needs. Measure arrival and completion rates with representative job sizes. Twenty is an illustrative number here; copying it into an unrelated queue provides formatting, not capacity planning.

Cap growth at a useful limit

Relate the maximum to cluster capacity and downstream budgets such as database connections. If ten workers each open many connections, the database can become the limiting resource. Check saturation and completion throughput rather than celebrating a larger Pod count.

Give one controller a coherent ownership story

Review existing HPAs, deployment tooling, and other replica-setting automation before introducing KEDA. Conflicting desired replica counts make diagnosis difficult. Document which controller owns scale decisions and how operators can safely suspend or reverse the pilot.

Verify the idle-to-working path

Begin at zero in a controlled test, introduce a known job, and measure the time until useful work completes. Include image pull, scheduling, startup, and broker connection delay. Choose a positive minimum if the observed delay fails the workload's requirement.

Common Mistakes

Bad: Interpret a missing metric as an empty queue.

Correct: Inspect errors and conditions, and test an explicit metric-loss policy.

Bad: Assume queue drain means all business work has committed.

Correct: Track in-flight work, acknowledgments, and downstream outcomes separately.

Bad: Add replicas until an unhealthy dependency becomes responsive.

Correct: Bound concurrency, inspect the bottleneck, and use recovery or backpressure appropriate to that dependency.

FAQ

Does KEDA replace HPA?

For this deployment pattern, they cooperate. Understand the zero-to-active boundary and the HPA's active-replica behavior when interpreting a scaling timeline.

Does scale to zero guarantee savings?

No particular savings follow from this configuration alone. Account for the rest of the cluster, event source, startup costs, and latency requirements before making a financial comparison.

Can the manifest be applied as-is?

Only after its stated prerequisites, permissions, and workload assumptions have been satisfied in an authorized test environment. The example has not been run against a Kubernetes cluster.

What should be monitored besides replicas?

Useful measures include job age, ready and in-flight counts, completion and failure rates, scaler conditions, startup time, and downstream saturation. Choose alerts from the service's actual processing objective.