Context
KEDA decides whether to create replicas or jobs by polling a trigger such as a queue. That polling component needs credentials to read the signal. The worker it creates separately needs credentials to consume messages. Giving only the worker an identity can leave the scaler unable to see demand.
Prerequisites are the AKS namespace, KEDA add-on state, ScaledObject or ScaledJob specification, trigger authentication reference and queue identity. Obtain read access to scaling status and operator logs. Record whether the symptom is no scale-out, pending workers or workers that start and cannot process messages.
1. Confirm the scaling resource and demand
Read the deployed scaling object, including target name, trigger type, queue or subscription name, polling behavior and limits. A ScaledObject adjusts a target workload; a ScaledJob creates jobs with a job template. Their status and successful-processing checks differ.
Inspect actual queue demand with an authorized management view. Confirm the namespace and entity match the trigger. Scheduled, locked or otherwise unavailable messages may not represent immediately consumable work. Compare the queue observation with KEDA status during the same interval instead of inferring demand from a producer log alone.
2. Inspect scaler authentication
Read the referenced TriggerAuthentication resource and its identity configuration. Verify which principal the scaler uses to query the service. Check federation and minimum required data or management permissions for that specific scaler and supported version. An application pod's service account does not automatically authorize the KEDA operator.
Review scaler conditions and sanitized operator errors. Authentication rejection, unreachable private endpoint and invalid entity name can all produce an apparently quiet scaling response. Classify the error before increasing replica limits. More workers are irrelevant if the scaler cannot determine that work exists.
3. Check the created worker independently
If scale-out occurs, inspect the pod or job template's service account, workload identity label and projected credential configuration. Validate the worker's permission to receive and settle messages. Registry pull authorization is another separate prerequisite; a correctly scaled job can remain unable to start its image.
Verify that the target workload becomes ready and performs the intended acknowledgement only after successful business processing. Bound concurrency to downstream capacity. A scaler threshold is a scheduling decision, not a guarantee that every created worker can complete its work safely.
Diagnostic checkpoints
| Symptom | Likely stage | Next evidence |
|---|---|---|
| Queue grows, scaler not ready | Signal access | Trigger authentication and logs |
| Scaling active, no pod starts | Kubernetes scheduling | Pod events and resources |
| Pod starts, receive denied | Worker identity | Service account and data role |
| Many pods, backlog persists | Processing capacity | Completion rate and downstream load |
Illustrative scenario
A hypothetical Service Bus consumer has correct workload identity credentials and processes messages when manually scaled. At zero replicas, KEDA cannot authenticate to read the queue signal. Reviewing TriggerAuthentication reveals the independent scaler configuration. This example illustrates identity separation without asserting a real customer's scaling outcome.
Verification and scaling SOP
Use an approved test message and observe the full sequence: visible demand, scaler activation, worker start, business completion and acknowledgement. Verify the return toward idle after the queue drains. Repeat from zero replicas because a warm worker can hide a broken activation path.
Document scaler and worker principals separately in the SOP. Monitor authentication errors, time to first worker and processing completion. Review permissions when changing trigger types or KEDA versions, and retest activation after identity or private networking changes.
Explore Clouvenix containers kubernetes for implementation and operational handover.