keda

Design, debug, and review KEDA (Kubernetes Event-Driven Autoscaling) ScaledObject and ScaledJob resources.

Mode: generate

Write a production-ready ScaledObject or ScaledJob from a description.

Steps:

1. Identify: target workload kind (Deployment / StatefulSet / Job), trigger type, and whether scale-to-zero is acceptable
2. Choose the right resource kind:
   • Long-running service → ScaledObject
   • Batch processing per message → ScaledJob
3. Generate with:
   • apiVersion: keda.sh/v1alpha1
   • scaleTargetRef.name matching the exact Deployment/StatefulSet/Job name
   • minReplicaCount: 0 only if the service can tolerate cold-start latency; otherwise minReplicaCount: 1

Scale-to-zero warning: Setting minReplicaCount: 0 means the Deployment will have 0 replicas when the queue/metric is empty. Cold-start latency applies — confirm this is acceptable before enabling.

• pollingInterval and cooldownPeriod sized to the workload pattern (see table in references/keda.md)
• Trigger-specific metadata with activationThreshold/activationQueueLength set to avoid flapping on sparse events
• authenticationRef pointing to a TriggerAuthentication — never inline credentials in the ScaledObject
• For AWS: prefer IRSA (podIdentity.provider: aws) over static key/secret pairs

1. Generate the companion TriggerAuthentication or ClusterTriggerAuthentication
2. Show validation command: kubectl describe scaledobject <name> -n <ns> and the expected Active: true condition

Mode: debug

Diagnose why a ScaledObject or ScaledJob is not scaling as expected.

Steps:

1. Collect:

   kubectl get scaledobject -n <namespace>
   kubectl describe scaledobject <name> -n <namespace>
   kubectl get hpa -n <namespace>
   kubectl describe hpa keda-hpa-<scaledobject-name> -n <namespace>
   kubectl logs -n keda -l app.kubernetes.io/name=keda-operator --tail=100
   kubectl logs -n keda -l app.kubernetes.io/name=keda-operator-metrics-apiserver --tail=100
   

2. Check the ScaledObject Conditions block:
   • Active: false → scaler is not detecting events (check trigger config and auth)
   • Ready: false → KEDA cannot reach the target deployment (check scaleTargetRef.name)
   • Fallback: true → metric fetch is failing; KEDA is using fallback replicas
3. Check HPA for <unknown> targets — indicates metrics adapter cannot reach the external source
4. Work through this checklist in order:
   • External source reachable from the KEDA namespace?
   • TriggerAuthentication secret exists and has correct keys?
   • activationThreshold too high for current event volume?
   • minReplicaCount preventing scale-to-zero?
   • Conflicting HPA on the same Deployment?
   • cooldownPeriod not yet elapsed?
5. State the most likely root cause with the exact field or resource to fix
6. Show the corrected spec section and the command to verify it