KEDA

Definition

KEDA, commonly expanded as Kubernetes Event-driven Autoscaling, is an open-source controller and external-metrics provider for Kubernetes. A KEDA scaler observes an event source and reports whether a workload should be active and what metric value should drive capacity. KEDA uses that information either to manage a scalable workload through a ScaledObject or to create Jobs from a ScaledJob.

“Event-driven” does not mean every source pushes an event into KEDA. Many built-in scalers poll a queue, service, database, or metrics endpoint; external push scalers can stream activation state. The event is operational demand represented through the chosen scaler's semantics.

KEDA is not an event broker, queue, scheduler, node provisioner, generic monitoring database, or AI safety system. It extends workload autoscaling. Node capacity still belongs to a node autoscaler, batch admission may belong to Kubernetes Kueue, and the correctness and authorization of queued work remain application responsibilities.

Snapshot

• Primary inputs: activity and metric values returned by built-in or external scalers.
• Long-running workload path: ScaledObject plus the KEDA operator, KEDA metrics API server, and Kubernetes HorizontalPodAutoscaler.
• Batch path: ScaledJob plus a Job template; KEDA creates Jobs directly rather than placing an HPA in that path.
• Scale-to-zero boundary: KEDA handles activation from zero and deactivation to zero; HPA handles the ordinary one-to-many replica range.
• Security boundary: KEDA may read credentials and external metrics and may update the /scale subresource, so its RBAC, authentication objects, network paths, and admission controls are security-sensitive.
• Not a guarantee: more replicas do not prove that work is valid, downstream capacity exists, latency will improve, or a service-level objective is met.

Architecture and Control Loop

KEDA 2.20 documents three in-cluster components:

• keda-operator: watches KEDA custom resources, builds scalers, manages the generated HPA, and directly handles scaling between zero and one replica.
• keda-metrics-apiserver: exposes scaler values through Kubernetes' aggregated external.metrics.k8s.io API so HPA can calculate desired replicas above one.
• keda-admission-webhooks: validates and mutates KEDA resources, including checks intended to prevent two autoscalers from controlling the same target.

Despite the similar name, keda-metrics-apiserver is not Kubernetes Metrics Server. Metrics Server normally supplies CPU and memory through metrics.k8s.io; KEDA supplies event-source metrics through external.metrics.k8s.io. CPU- or memory-only triggers are a special case: HPA reads their data from Metrics Server, and they cannot supply the activation signal needed to return from zero.

For a ScaledObject, the operator polls triggers while the target is at zero. When a trigger becomes active, the operator activates the workload. Once replicas are running, HPA queries metrics served by KEDA and controls scaling in the one-to-many range. When triggers become inactive and the scale-to-zero cooldown has elapsed, KEDA can deactivate the target. The KEDA cooldown applies to the transition to zero; HPA behavior and stabilization govern ordinary scale-up and scale-down above zero.

The version 2.20 ScaledObject reference defaults to a 30-second KEDA polling interval, a 300-second scale-to-zero cooldown, zero minimum replicas, and 100 maximum replicas. Those are software defaults, not recommended production values. Polling, HPA sync, source freshness, application startup, and node provisioning are separate clocks.

With multiple ordinary triggers, KEDA exposes metrics and Kubernetes HPA selects the largest replica recommendation, subject to the configured maximum. KEDA's optional scaling modifiers instead compose named trigger values into one external metric. A formula is executable scaling policy: it needs unit checks, missing-data behavior, tests, and change review.

The external metrics API is also a cluster-level integration point. KEDA's operations guide notes that only one active metrics provider can own external.metrics.k8s.io in a cluster. Operators using Kubernetes Prometheus Adapter or another provider must inspect the registered APIService objects and decide which component serves which metrics API rather than assuming adapters can coexist without coordination.

Resource Models

ScaledObject is for a Deployment, StatefulSet, or custom resource that exposes the Kubernetes /scale subresource. The scale target must be in the same namespace as the ScaledObject. The object identifies the target, triggers, activation and scaling thresholds, replica bounds, timing, fallback behavior, and optional HPA behavior or composite-metric policy.

ScaledJob is for discrete work. It contains a Job template and triggers; on each poll KEDA calculates how many Jobs to create, bounded by its scaling strategy and maxReplicaCount. Version 2.20 defaults the polling interval to 30 seconds and the per-poll maximum to 100. A Job is not automatically one event: the scaler's target value, running and pending Jobs, selected scaling strategy, message acknowledgement, and application concurrency determine the relationship.

Authentication can be embedded in a workload reference, delegated through namespaced TriggerAuthentication, or shared through cluster-scoped ClusterTriggerAuthentication. The cluster-scoped form is reusable across namespaces and therefore has a larger blast radius. KEDA also supports external scalers over gRPC; TLS and client certificates are available, while disabling certificate validation with unsafeSsl removes server authentication and should not be treated as a production shortcut.

AI and Agent Workloads

AI infrastructure often has demand that CPU and memory do not describe well. Embedding pipelines wait on document queues. Evaluation workers drain task streams. Moderation, transcription, synthetic-data generation, batch inference, and coding-agent sandboxes may arrive as discrete jobs. Online inference may be constrained by requests in flight, tokens waiting, batch occupancy, GPU memory, or queue age rather than average CPU.

KEDA can translate one of those signals into workload capacity, but signal choice is policy. Queue depth measures items, not age, urgency, token count, GPU time, or downstream cost. A short queue of large prompts can require more capacity than a long queue of small requests. A backlog can grow because consumers are slow, because a dependency is failing, or because an attacker is submitting work. Scaling all three cases identically can waste money or amplify harm.

Scale-to-zero is attractive for costly inference and agent pools, but the full cold-start path can include KEDA polling, pod scheduling, node or accelerator provisioning, image pull, model loading, cache warming, and readiness. KEDA does not shorten those stages. User-facing services may need a nonzero floor, pre-provisioned nodes, or a latency-aware design; asynchronous evaluation may tolerate the delay.

For ScaledJob, workers need bounded retries, idempotent or deduplicated side effects, timeouts, cleanup, and clear acknowledgement semantics. An agent Job that sends mail, changes code, or calls external tools still needs authorization, sandboxing, and human gates. Autoscaling multiplies execution capacity; it does not grant legitimate authority.

Current Context

As of August 12, 2026, KEDA 2.20.2 was the latest stable upstream release, published July 31, while the 2.21 documentation was marked unreleased. The 2.20 catalog listed 77 scalers. KEDA's 2.20 cluster guide listed Kubernetes 1.33 through 1.35 as its tested compatibility window and described support as community-provided on a best-effort basis.

The 2.20.2 patch notes include fixes for operator panics, a zero-delay gRPC reconnect loop, shared HTTP transports, and negative external metric handling. That is a reminder to record the patch version, not merely “KEDA 2.20,” and to rehearse upgrades. The 2.20.0 release also moved event recording to events.k8s.io and warned installations with custom or restricted RBAC to add the needed event permissions before upgrading.

KEDA became a CNCF Graduated project on August 22, 2023 after project-governance and security-review work. Graduation is evidence about the open-source project's maturity; it does not certify a local scaler formula, credential scope, queue contract, or cost ceiling.

Governance and Safety

KEDA should be governed as a control-plane component that can turn a remotely observed number into compute, network calls, data access, and external side effects. Useful controls include:

• Constrain authority. KEDA watches all namespaces by default, and its default role supports broad reads and updates to scalable resources. Use WATCH_NAMESPACE, restrict custom scale-target kinds, inspect rendered Helm or YAML RBAC, and grant only the namespaces and resource kinds the deployment needs.
• Constrain secret access. The cluster guide warns that default permissions can include reading Secrets across namespaces. Evaluate KEDA_RESTRICT_SECRET_ACCESS, prefer short-lived workload identity where supported, isolate shared authentication objects, rotate credentials, and audit who may create or reference them.
• Protect scaler traffic. Allow only required egress to brokers, cloud APIs, databases, telemetry services, and external scalers. Use Kubernetes NetworkPolicy, validate TLS, avoid unsafeSsl, and use least-privilege read credentials for metric collection.
• Make admission deliberate. KEDA 2.20 registers its admission webhook with failurePolicy: Ignore by default. If validation is a safety boundary, evaluate fail-closed operation and its availability tradeoff, prevent casual use of the HPA-ownership bypass annotation, and add Kubernetes admission policy for local bounds such as maximum replicas or approved scaler types.
• Bound multiplication. Set workload-specific maxima and pair them with ResourceQuota, LimitRange, cloud quotas, API rate limits, budget alerts, and concurrency controls. A replica maximum does not cap retries, per-pod concurrency, tokens, GPU hours, node provisioning, or third-party API spend.
• Separate service classes. User-facing inference, safety review, batch evaluation, and experimental agents should not share an unbounded queue or credential set. Use distinct namespaces, quotas, priorities, and admission policies so an evaluation flood cannot starve a safety or customer path.
• Design for downstream pressure. Before scaling out, test database connections, broker partitions, external rate limits, model-server capacity, and write amplification. Backpressure and load shedding may be safer than more workers during a dependency failure.
• Observe the controller. KEDA exposes Prometheus metrics for scaler activity, scaler values, retrieval latency, errors, paused objects, build information, and its metrics API server. Connect those signals to AI Agent Observability, Kubernetes events, audit logs, cost telemetry, and an owned incident path.

Fallback is a resilience setting, not evidence that the event source is healthy. A static fallback replica count can preserve some capacity after repeated scaler errors, but it may be too small for real demand or unnecessarily expensive during an outage. Document which failures trigger it, its duration, its alert, and how an operator returns to measured scaling.

Failure Modes

• Wrong denominator: scaling on queue items when work varies by token count, file size, partition, tenant, or expected runtime.
• Metric staleness: a cached, delayed, missing, or malformed value causes late activation, blocks scale-down, or creates oscillation.
• Control-loop collision: another HPA or ScaledObject manages the same target, especially when webhook validation fails open or is bypassed.
• Capacity illusion: KEDA creates pods or Jobs, but they remain Pending because no suitable CPU, memory, GPU, topology, or quota is available. Workload scaling and node autoscaling are separate loops.
• Retry amplification: poison messages, failed acknowledgements, or non-idempotent Jobs produce duplicate work and side effects as capacity grows.
• Downstream collapse: more consumers overload a database, model endpoint, rate-limited provider, review team, or shared filesystem.
• Economic denial of service: an attacker or malfunction inflates the trigger and converts cheap event creation into expensive accelerator, model, or tool execution.
• Cold-start breach: scale-to-zero saves idle capacity but misses a latency objective because node provisioning and model loading dominate activation.
• Credential overreach: a globally reusable authentication object or broad operator role lets one namespace query another tenant's event source or Secrets.

Evidence and Verification

A governance-grade deployment record should preserve:

• KEDA core and chart versions, image digests, installation source, upgrade notes, Kubernetes version, CRD versions, generated manifests, and rollback procedure;
• watched namespaces, operator and metrics-server RBAC, scale-target kinds, admission webhook policy, APIService ownership, network policy, certificate configuration, and high-availability settings;
• each ScaledObject or ScaledJob, owner, target, scaler type and maintainer, metadata schema, metric units, query, activation threshold, target value, timing, replica bounds, formula, HPA behavior, Job strategy, fallback, and authentication reference;
• the event contract: whether depth includes in-flight or delayed items, acknowledgement and retry behavior, dead-letter handling, partition limits, per-worker concurrency, and expected service time;
• resource requests, node or accelerator constraints, quotas, downstream connection budgets, third-party rate limits, service objectives, and cost ceiling; and
• dashboards, alerts, scale events, incident links, change approval, last load test, and evidence that stopped or paused scaling can be restored safely.

Verification should cover more than valid YAML. Test idle-to-active latency, one-to-many scale-out, backlog drain, scale-down, a missing or slow metric source, invalid credentials, broker partition limits, unschedulable pods, a downstream outage, a poison task, and attempted metric inflation. Inspect the generated HPA, KEDA conditions and events, actual pod or Job counts, queue age, completed work, errors, node changes, and cost. The claim to verify is not “KEDA scaled”; it is “the system admitted and completed legitimate work within its safety, reliability, and budget bounds.”

Source Discipline

Use versioned KEDA reference pages for CRD fields and defaults, the matching scaler page for metric and authentication semantics, upstream release notes for changes and upgrade hazards, and Kubernetes documentation for HPA, Jobs, metrics APIs, admission, quotas, and node autoscaling. The KEDA homepage and CNCF project page establish identity and project status; they are not configuration references.

Distinguish stable from unreleased documentation, built-in from external or experimental scalers, core KEDA from add-ons, and community support from a commercial support contract. A vendor dashboard or Helm value may describe one distribution rather than upstream behavior. A claim should name the KEDA version, Kubernetes version, scaler type, metric definition, authentication path, target, and observation date.

Documentation can also disagree. When an overview, example, generated chart, and CRD reference differ, use the reference for the installed release, inspect the installed CRD and rendered manifest, and verify runtime behavior. Never infer metric units from a trigger name alone.

Spiralist Reading

Spiralism reads KEDA as a bell that converts waiting work into a request for capacity.

The bell does not know whether the queue is just, urgent, wasteful, or malicious. Its institutional value comes from making the conversion inspectable: which signal may summon machines, how many, under whose credentials, at what cost, and with what condition for standing down.

Open Questions

• Should an AI workload scale on queue depth, oldest-item age, token-weighted work, predicted service time, or a composite constrained by downstream health?
• How should platforms reserve capacity for safety review and urgent user work without letting those labels become an unreviewed priority bypass?
• Which tenants may create ScaledObject, ScaledJob, and cluster-scoped authentication resources, and how is cross-tenant leakage tested?
• What is the safe response when backlog rises because a dependency is failing rather than because legitimate demand increased?
• Which scale and cost records should be retained so an organization can reconstruct an autoscaling incident without retaining user-level data in metrics?

Related Pages

• Kubernetes HorizontalPodAutoscaler
• Kubernetes Prometheus Adapter
• Kubernetes Metrics Server
• Kubernetes kube-state-metrics
• Kubernetes Cluster Autoscaler
• Kubernetes Karpenter
• Kubernetes Kueue
• Kubernetes JobSet
• Kubernetes Admission Webhooks
• Kubernetes ResourceQuota
• Kubernetes LimitRange
• Kubernetes NetworkPolicy
• Kubernetes ServiceAccount Tokens
• Kubernetes Audit Logging
• AI Agent Observability
• AI Inference Providers
• AI Compute
• Compute Governance

Sources

• KEDA, Kubernetes Event-driven Autoscaling, project overview, reviewed August 12, 2026.
• KEDA Documentation 2.20, KEDA concepts and architecture, reviewed August 12, 2026.
• KEDA Documentation 2.20, Scalers, versioned catalog, reviewed August 12, 2026.
• KEDA Documentation 2.20, ScaledObject specification, reviewed August 12, 2026.
• KEDA Documentation 2.20, ScaledJob specification, reviewed August 12, 2026.
• KEDA Documentation 2.20, Authentication and External scaler, reviewed August 12, 2026.
• KEDA Documentation 2.20, Cluster requirements and operations, including compatibility, namespace, RBAC, external-metrics, and high-availability guidance, reviewed August 12, 2026.
• KEDA Documentation 2.20, Admission webhooks and Security, reviewed August 12, 2026.
• KEDA Documentation 2.20, Prometheus integration, reviewed August 12, 2026.
• kedacore, KEDA v2.20.2 release notes, July 31, 2026; release status checked August 12, 2026.
• KEDA Documentation 2.21, KEDA concepts, unreleased-version status checked August 12, 2026.
• KEDA, Support, community-support policy, reviewed August 12, 2026.
• Kubernetes Documentation, Horizontal Pod Autoscaling and Node Autoscaling, reviewed August 12, 2026.
• Cloud Native Computing Foundation, KEDA project page, project maturity and timeline, reviewed August 12, 2026.

Return to Wiki