Autoscaling Controller  ·  View 25 of 37  ·  4 · Runtime

Four Classes of Target

The same loop, four driving signals, four definitions of "serving".

Editable source SVG draw.io All views
Driving signal Policy form Actuation Counted when Stateless service Concurrency arrival x service Target tracking VMSS capacity LB registered Queue worker pool Oldest message age leads demand Target tracking age setpoint Replica count Subscription active Batch consumer Consumer lag plus schedule Scheduled + step Replica count Partition assigned Node group Unschedulable pods derived, not raw Derivative of above no policy of its own AKS node count Node Ready Four Classes of Target, One Loop The node group has no independent opinion about demand. It supplies what the workload layer declared, or reports unmet demand. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • "Counted when" differs per class and is the most commonly wrong part of an autoscaler: a registered instance, an active subscription, an assigned partition, a Ready node.
  • The node group has no policy of its own. Its desired count is derived from what the workload layer declared.
  • Batch consumers combine a schedule with lag because their demand is known in advance and their backlog is not.

Why not one policy form for all

  • Utilization is meaningless for the queue worker and the batch consumer, both of which are I/O-bound.
  • Concurrency is the request-serving equivalent of backlog: arrival rate × service time, a derived signal rather than a measured one.

Omitted here

  • Vertical scaling targets, which declare a resource quantity rather than an instance count, follow the same loop and are not drawn separately.