KEDA Autoscaling

​

Prerequisites

• KEDA installed in your cluster (KEDA deployment docs).
• A Metoro API key. We recommend a dedicated key per cluster, bound to a read-only telemetry role (created in step 1 below).

​

Setup

​

1. Create a read-only telemetry role, group, and API key

1. Create the role. In Settings → Users & Groups → Roles, click Create Role (say, keda-autoscaler):
   • Grant no resource permissions. Custom roles are deny-by-default, so leaving them empty means the key can do nothing except what you grant next.
   • Under Telemetry Permissions, grant the signals your scaling queries use: metrics for metric queries, plus traces or logs if you scale on trace- or log-derived signals. If you do not yet know what you will scale on, just select all the signal types; the role is still read-only, and you can narrow it later.
   • Optionally scope the grants with match rules (for example to one namespace or environment). The scaler evaluates queries under the key’s telemetry scope, so a scoped role means scaling queries can only see the telemetry you granted, and a query outside that scope simply evaluates against no data.
2. Create a group bound to the role. API keys are assigned to groups, not roles directly. In the Groups tab, create a group (say, keda-autoscalers) and bind it to the keda-autoscaler role only.
3. Create the API key. From the API keys page, create the key assigned to just that group.

​

2. Store your API key in a Secret

apiVersion: v1
kind: Secret
metadata:
  name: metoro-api-key
stringData:
  apiKey: metoro_secret_...

​

3. Create a TriggerAuthentication

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: metoro-trigger-auth
spec:
  secretTargetRef:
    - parameter: bearerToken
      name: metoro-api-key
      key: apiKey

​

4. Create a ScaledObject

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: checkout-scaler
spec:
  scaleTargetRef:
    name: checkout
  minReplicaCount: 1
  triggers:
    - type: prometheus
      metadata:
        serverAddress: https://scaler.us-east.metoro.io   # on-prem: http://scaler.<namespace>.svc:8080
        query: 'count(traces{server.service.name="/k8s/production/checkout"})'
        queryParameters: language=metoroql,window=60,reduce=avg
        threshold: "100"
        timeout: "15000"   # milliseconds
        authModes: bearer
      authenticationRef:
        name: metoro-trigger-auth

​

Trigger metadata reference

​

Debugging with curl

curl -sG https://scaler.us-east.metoro.io/api/v1/query \
  -H "Authorization: Bearer $METORO_API_KEY" \
  --data-urlencode 'query=count(traces{server.service.name="/k8s/production/checkout"})' \
  --data-urlencode 'language=metoroql' \
  --data-urlencode 'window=60'

{"status":"success","data":{"resultType":"vector","result":[{"metric":{},"value":[1753799000.123,"142.5"]}]}}

​

Failure semantics

• Missing data is an error, not zero. If the window contains no datapoints, the endpoint returns 404 with errorType: no_datapoints rather than reporting 0. Many metrics are emitted infrequently or in batches, so an empty window often just means the next datapoint has not arrived yet; treating that as a literal 0 would scale your workload to minimum between emissions. Erroring instead lets the HPA hold replicas until data appears. If your metric is emitted infrequently, size window comfortably larger than the emission interval so the window always contains datapoints.
• Stale data is an error. Metoro serves the scaling signal from a cache refreshed on KEDA’s polling cadence. An interruption in refresh is invisible for a while (the cached value keeps serving, holding your scale steady); past roughly ten minutes of failed refreshes the signal returns 503 with errorType: stale_data instead of serving fiction.
• Errors hold your current replica count. Any non-2xx response is a scaler error to KEDA: the HPA cannot compute a desired replica count, so it keeps the workload at whatever size the last good signal produced. This is the default and usually what you want: capacity tracks the last real measurement through an outage.
• fallback replaces holding with a pinned count; use it deliberately. KEDA’s fallback engages after failureThreshold consecutive scaler errors and converges the workload to fallback.replicas, in both directions: a workload that was at 20 replicas when the signal failed gets scaled down to a fallback of 6. Configure it only if you specifically want a fixed known-safe capacity during outages (for example, if an outage coinciding with being scaled low worries you more than tracking the last measurement), and size it as safe capacity, not as a minimum. It also only applies to AverageValue metrics (the default).

​

On-premises

scaler:
  enabled: true

​

Troubleshooting