Learn KEDA - Advanced Scalers & Ecosystem

#Introduction

In episode 16 we saw KEDA working alongside Karpenter to scale nodes. Up to this point, our examples revolved around SQS and Redis — but KEDA has more than 70 scalers, and many work outside the classic queue pattern. This episode covers Advanced Scalers & Ecosystem: scalers that interact with external APIs, push events, and how KEDA pairs with Argo Rollouts, Knative, and service mesh. After this, your mental model of "what can scale what" will broaden drastically.

#GitHub Scaler

The GitHub scaler allows autoscaling based on GitHub activity — not a queue. A real example: scaling pipeline runners or labeling bots based on the remaining API rate limit or the number of unresolved issues. KEDA reads the GitHub API with a personal token:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: github-triage-bot
spec:
  scaleTargetRef:
    name: triage-bot
  maxReplicaCount: 5
  triggers:
    - type: github
      metadata:
        owner: devnull
        repository: devvnull.vercel.app
        query: "is:issue is:open"
      authenticationRef:
        name: github-token

The metric KEDA calculates from the query above is the number of open issues. The triage bot scales up when issues pile up, then drops to zero when the triage queue is clean. Another popular case: a query based on the rate limit — the bot stops scaling as github.rate_limit.remaining approaches zero, preventing the API from being throttled.

#Azure Storage Queue & GCP Cloud Storage

In episode 8 we covered SQS. Two other cloud analogs use a similar scheme with their own credential providers.

#Azure Storage Queue

scaledobject-azure-queue.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: azure-worker
spec:
  scaleTargetRef:
    name: azure-worker
  maxReplicaCount: 30
  triggers:
    - type: azure-queue
      metadata:
        queueName: jobs
        queueLength: "10"
        connectionFromEnv: AZURE_STORAGE_CONNECTION_STRING

Authentication can use a connection string from env, or podIdentity with Azure workload identity.

#GCP Cloud Storage

The GCP Cloud Storage scaler works based on the number of objects in a particular bucket or folder:

scaledobject-gcs.yaml

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: gcs-processor
spec:
  scaleTargetRef:
    name: gcs-processor
  maxReplicaCount: 20
  triggers:
    - type: gcp-storage
      metadata:
        bucketName: ingest-bucket
        prefix: "raw/"
        count: "10"

KEDA counts the objects in raw/; once it exceeds 10, the gcs-processor replicas increase. This is the typical data pipeline pattern: files land, workers process, files get deleted, replicas drop — compute costs only exist when there's data.

#External Push & Community Scalers

Some events can't be efficiently polled — like a message broker that needs to push, or an internal system with a proprietary API. KEDA provides two paths:

• external-push scaler: the workload is scaled up by an external trigger via a push gRPC call to KEDA — ideal for events that come rarely but must be fast, avoiding expensive polling. For internal systems, use a custom gRPC external scaler (covered in depth in episode 10).
• Community scalers: managed outside the core kedacore/keda repo, for example scalers for Jenkins, Bitbucket, or certain observability tools. Always check maturity and support before using one in production — community scalers don't get the same guarantees as official scalers.

#KEDA + Argo Rollouts

KEDA pairs naturally with Argo Rollouts for metric-aware canary and blue-green deployments. Argo Rollouts shifts traffic gradually to the new version; its analysis can consume KEDA metrics. This is the combination that makes deployment assessment quality-based — not just "pods ready".

rollout-with-analysis.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout-service
spec:
  strategy:
    canary:
      steps:
        - setWeight: 25
        - analysis:
            templates:
              - templateName: error-rate
  selector:
    matchLabels:
      app: checkout-service
  template:
    metadata:
      labels:
        app: checkout-service
    spec:
      containers:
        - name: checkout
          image: ghcr.io/devnull/checkout:v2

The analysis template uses Prometheus metrics that can come from a KEDA scaler:

analysis-error-rate.yaml

apiVersion: argoproj.io/v1beta1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
    - name: error-rate
      prometheus:
        address: http://prometheus.monitoring:9090
        query: sum(rate(http_requests_total{status="5xx"}[5m]))

When the error rate crosses the threshold, the Rollout aborts the canary and returns traffic to the old version. KEDA autoscales pods; Argo Rollouts manages the release.

#KEDA + Knative: Two Schools of Scale-from-Zero

Knative Serving has its own autoscaler that scales a Revision from zero based on concurrency and requests. KEDA and Knative can both scale-to-zero, but with different philosophies:

They're complementary: use Knative for request-driven APIs that need scale-from-zero with automatic traffic routing, and KEDA for workers triggered by backlog. Where Knative uses an activator to buffer requests during scale-to-zero, the KEDA HTTP Add-on uses an interceptor for the same role.

#Service Mesh Integration

With a service mesh (Istio/Linkerd), KEDA still works at the Deployment layer — regardless of how traffic is routed. What you need to watch:

• Istio sidecars add to the cold start time of new pods; when scaling up from zero, make sure the budget includes init container readiness.
• The mesh's adaptive concurrency limit (ACL) pattern actually pairs with the metrics KEDA consumes: KEDA scales replicas, the mesh manages concurrency per replica.
• KEDA's HTTP scaler can read request metrics from the mesh (Istio istio_requests_total) as a trigger — a replacement for the interceptor when all traffic goes through the mesh.

#Common Mistakes

1. Using a community scaler without reviewing the code. In production, choose official scalers or ones your own organization maintains.
2. GitHub token without the repo scope. The GitHub scaler fails with 403 when the token has no read permission — test with curl -s https://api.github.com/rate_limit before creating the ScaledObject.
3. Forgetting prefix in GCP Storage. Without a prefix, KEDA counts every object in the bucket — unexpected sudden scale-up.
4. Mixing Rollout and a regular HPA on the same Deployment. Argo Rollouts recommends using KEDA/analysis instead of classic HPA so the new version isn't scaled by old metrics.
5. Knative and KEDA on the same Deployment. Choose a single scaling owner per Deployment to avoid two controllers fighting over replicas.

#Conclusion

This episode broadened the scaler horizon: GitHub for repo activity, Azure Storage Queue and GCP Cloud Storage for cloud data pipelines, external-push for events that can't be polled, and community scalers that need careful review. At the ecosystem layer, KEDA works alongside Argo Rollouts for metric-aware canary, Knative for HTTP scale-from-zero, and service mesh for concurrency control.

Points you should take away:

• The GitHub scaler can trigger autoscaling from a rate limit or issue count.
• Azure Queue and GCS use the same authentication patterns as other cloud scalers.
• external-push for rare-but-fast events; external scaler for internal systems.
• Argo Rollouts assesses release quality; KEDA manages the replica count.
• Knative and KEDA have different scale-to-zero philosophies — pick per workload type.

With so many scalers and integrations, when something fails in production you need to know how to investigate it. In the next episode, 18, we discuss Troubleshooting & Monitoring: diagnosing ScaledObjects with kubectl, reading operator logs, making use of keda_scaler_* metrics, and solving common issues like Unknown status, stale HPA updates, and webhook errors. See you in episode 18!