KEDA Skill

Anti-Hallucination Rule

Before generating production-shaped output with this skill, verify every identifier, command, version, status, and example against the current authoritative source for the surfaces this skill covers: official product documentation, the CLI/SDK/reference surface, or the organisation's published standard. Anything that cannot be verified must be marked [VERIFY] and paired with the verification command or source. Do not produce final artifacts from memory when verification is blocked; emit a labelled skeleton with [VERIFY] markers and the verification commands instead.

Use this skill for Kubernetes Event-driven Autoscaling (KEDA) across Azure Container Apps and AKS. KEDA is the scaling brain for event-driven workloads on both platforms.

Version currency

KEDA releases a new minor roughly every four months; supported for two release cycles. Current line (verified 2026-08-26):

• Latest stable: v2.20.2 (2026-07-31). Notable: a dedicated HPAActive condition on ScaledObject: transient HPA metric gaps no longer flip the Ready condition to False (relevant when triaging "not ready" scaled objects).
• v2.20.0 (2026-06-01) introduced the OpenSearch and Elastic Forecast scalers (part of the "70+ scalers" surface), scalingModifiers fallback behavior, AWS External ID support in pod identity, and scaler HTTP request metrics. [VERIFY] Do not cite CVE-2026-42151/42154/40179 against this release; those CVE numbers belong to Prometheus, not KEDA; the corresponding KEDA fix (kedacore/keda issue #7868) is listed as Unreleased in the upstream CHANGELOG.md as of 2026-08-11, not shipped in v2.20.0, v2.20.1, or v2.20.2. Confirm current status against kedacore/keda/CHANGELOG.md before citing a fixed-in version.
• Upgrade note (2.20.0, breaking for custom RBAC): KEDA now records events via the events.k8s.io API group instead of the legacy core events. If you deploy with custom or restricted RBAC, grant the operator create/patch on events.k8s.io/events before upgrading, or event recording fails. The bundled manifests and Helm chart already include the permissions.
• Regression (v2.20.0–v2.20.1, fixed in v2.20.2): the generated manifests/Helm chart for these two releases dropped the legacy core "" events API group that client-go's event broadcaster also needs, silently breaking native KEDA events (ScaledObjectReady, KEDAScalersStarted, leader-election) even with the events.k8s.io RBAC above correctly granted. Upgrade straight to v2.20.2 rather than pinning to v2.20.0/v2.20.1.
• Kubernetes support: 2.20 → K8s 1.33–1.35 (each minor supports three K8s minors). Check the current matrix on keda.sh before planning upgrades.
• Next minor (v2.21, unreleased at verification): Liiklus scaler deprecated (upstream unmaintained); ClickHouse and GCP Spanner scalers staged on main. Temporal scaler breaking deprecations land in v2.21: buildId, selectAllActive, selectUnversioned removed — migrate to workerDeploymentName/workerDeploymentBuildId. Azure-side fixes staged: Event Hub duplicate-EntityPath fix. [VERIFY] against kedacore/keda/CHANGELOG.md before citing as shipped (v2.21 targeted ~second week of September 2026).
• HTTP Add-on: v0.14+ replaces HTTPScaledObject with InterceptorRoute (http.keda.sh/v1beta1); the old CRD is deprecated; don't author new ones.

Use When

Mandatory co-skills

KEDA on AKS vs ACA

AKS managed add-on version pinning: the AKS KEDA add-on's shipped KEDA version is tied to the cluster's Kubernetes minor version (mapping in the AKS managed add-ons column of the component version table), not to the latest upstream KEDA release this skill tracks (currently v2.20.2). The add-on also lags upstream and does not bundle KEDA's HTTP add-on. If you need a specific KEDA version or the newest release, install manually (operator or Helm) instead of the add-on. Note: KEDA 2.15+ removed pod-identity support ; use Workload Identity with newer versions.

Scaler selection decision framework

Scaling patterns

AKS prerequisite: the target Deployment (or StatefulSet) must exist before creating the ScaledObject that references it. Install KEDA first — AKS managed add-on (az aks update --enable-keda) or Helm (helm repo add kedacore https://kedacore.github.io/charts && helm install keda kedacore/keda -n keda --create-namespace).

ACA scale-rule syntax: ACA rules are http, tcp, or custom. Only http/tcp use their own block; every event-driven source (Service Bus, Event Hubs, Kafka, Redis, cron, …) is expressed as a custom rule carrying the KEDA scaler type + metadata (e.g. custom: { type: azure-servicebus, metadata: { queueName, namespace, messageCount } }). The abbreviated azureServiceBus: blocks below are shown for readability; map them to a custom rule in real Bicep/ARM/CLI.

Scale-to-zero

# ACA: HTTP-triggered scale to zero
scale:
  minReplicas: 0
  maxReplicas: 10
  rules:
    - name: http
      http:
        metadata:
          concurrentRequests: "10"
          targetValue: "10"

# AKS: KEDA ScaledObject (event-driven — core KEDA has no `http` trigger)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: my-app
spec:
  scaleTargetRef:
    name: my-app
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
    - type: azure-servicebus
      metadata:
        queueName: my-queue
        namespace: my-namespace
        messageCount: "10"

HTTP scale-to-zero on AKS is not a ScaledObject trigger. Install the KEDA HTTP Add-on and declare an InterceptorRoute (http.keda.sh/v1beta1, scaling on scalingMetric.concurrency and/or scalingMetric.requestRate) plus a plain ScaledObject for minReplicaCount/cooldown; the legacy HTTPScaledObject CRD is deprecated since add-on v0.14. The add-on's interceptor holds the first request while the workload scales from zero. ACA's http scale rule (concurrentRequests) is platform-native and unrelated to the add-on.

Always-on with event-driven scaling

# ACA: Worker that must never scale to zero
scale:
  minReplicas: 1
  maxReplicas: 20
  rules:
    - name: servicebus
      azureServiceBus:
        queueName: my-queue
        messageCount: "100"

Multiple scaler triggers

# Scale on HTTP traffic OR queue depth, whichever demands more
scale:
  minReplicas: 1
  maxReplicas: 50
  rules:
    - name: http
      http:
        metadata:
          concurrentRequests: "20"
    - name: queue
      azureServiceBus:
        queueName: orders
        messageCount: "50"

Critical rules

1. Never set minReplicas=0 on ingress-disabled workloads. Once scaled to zero, nothing restarts it.
2. CPU/memory scalers cannot scale to zero. A replica must be running to measure utilization.
3. Cooldown periods matter. Default 300s cooldown limits scale-to-zero thrash but delays scale-down (1..N scale-down is the HPA stabilization window, see advanced-patterns).
4. Queue scalers use message count, not age. A queue with 1 old message scales the same as 1 new message.
5. Verify scaler availability on your platform. ACA doesn't support all AKS scalers.

Anti-patterns

Related skills

• event-driven-messaging. Service Bus, Event Hubs, Kafka patterns

Bundles