Q: Your message processing microservice on AKS consumes orders from Azure Service Bus. During flash sales, 500,000 messages flood the queue in 2 minutes. Standard Horizontal Pod Autoscaler (HPA) based on CPU/memory scales too slowly, causing huge message processing lag. How do you implement KEDA with Azure Service Bus and Cluster Autoscaler to scale pods from 0 to 300 instances dynamically?

Activate the managed KEDA controller directly via Azure CLI:

• Enable Add-on: Executed az aks update --resource-group rg-aks --name aks-prod --enable-keda.
• Verify KEDA Operator: Confirmed keda-operator and keda-metrics-apiserver pods are running in the kube-system namespace.

Securely authenticate KEDA against Azure Service Bus without storing connection strings:

• TriggerAuthentication CRD: Created TriggerAuthentication referencing pod Workload Identity with identityId: $MANAGED_IDENTITY_CLIENT_ID.
• Azure RBAC: Granted the Managed Identity Azure Service Bus Data Receiver and Azure Service Bus Data Owner roles on the Service Bus namespace.

Define the scaling rules binding the deployment to queue message depth:

• ScaledObject Manifest: Applied ScaledObject targeting order-processor deployment with minReplicaCount: 0, maxReplicaCount: 300, and cooldownPeriod: 300.
• Trigger Spec: Configured azure-servicebus trigger with queueName: orders and messageCount: 50 (spawning 1 pod for every 50 pending messages).

Prevent pod scheduling bottlenecks when hundreds of pods are created simultaneously:

• Autoscaler Profile: Configured cluster autoscaler profile: az aks update -g rg-aks -n aks-prod --cluster-autoscaler-profile scan-interval=10s,scale-down-delay-after-add=10m,scale-down-unneeded-time=5m.
• Overprovisioning Buffer: Deployed a low-priority pause pod deployment to reserve spare node capacity, ensuring immediate scheduling of incoming worker pods while new nodes boot.