Horizontal scaling and demand signals
Horizontal scaling changes replica count or creates jobs from demand. KEDA evaluates triggers and activation; HPA or KPA controls the active replica loop. Choose a signal and workload shape before tuning polling intervals.
Choose a demand signal
Section titled “Choose a demand signal”| Signal / requirement | Capability or task |
|---|---|
| Queue, stream, event source or known schedule | Built-in KEDA scalers |
| HTTP rate or concurrency | HTTP scaling and integrations |
| Application metric | OTel scaling · General OTel tutorial |
| Useful historical pattern | Predictive scaling |
Use a ScaledObject for a long-running Deployment or StatefulSet; use a ScaledJob when each unit of work runs as a Kubernetes Job. The queue’s acknowledgement, retry and visibility rules still govern delivery.
Controllers and shared capacity
Section titled “Controllers and shared capacity”KEDA scalers supply demand signals; the controller determines active replica count. HPA and KPA ownership explains the control loops. Use Kedify Pod Autoscaler (KPA) for Kedify’s horizontal controller and Scaling Groups for a shared replica budget.
Activation and ownership
Section titled “Activation and ownership”For zero-to-one activation, the signal must remain observable while workload pods are stopped. CPU/memory emitted only by those pods cannot supply that evidence. Keep one writer for target replicas and configure generated HPA/KPA behavior through the ScaledObject. Use horizontal tuning and workload diagnostics to verify demand, desired capacity, ready pods and application outcome.
Return to the horizontal scaling family for direct capability discovery.