KEDA, HPA, and Kedify
HPA, KEDA and KPA have different responsibilities in the replica control loop.
Controller ownership
Section titled “Controller ownership”| Component | Responsibility | Use it when |
|---|---|---|
| Kubernetes HPA | Calculates a replica count from resource, custom or external metrics and updates the workload’s scale subresource. | CPU/memory or an existing metrics adapter provides your demand signal. |
| KEDA | Polls event sources, handles activation and scale to zero, and supplies metrics to a generated HPA. A ScaledJob creates Jobs instead. | Demand comes from queues, streams, schedules or other event sources. |
| Kedify Pod Autoscaler (KPA) | Optional tenant-scoped replacement for the HPA 1 ↔ N loop on selected ScaledObjects; reads external metrics directly from KEDA. | You need namespace-scoped controller ownership or to distribute autoscaling-controller load. |
With KPA enabled, KEDA still handles polling, activation, fallback metrics, cooldown and scale to zero. KPA reuses the ScaledObject model; it does not replace the scalers. See KPA enablement and scope before selecting it.
What Kedify adds
Section titled “What Kedify adds”Kedify distributes KEDA and adds controllers, scalers and management components. Select a capability for the requirement you have:
| Requirement | Documentation |
|---|---|
| HTTP requests, OTel metrics or forecast demand | Scaling signals |
| Change container CPU/memory | Vertical scaling |
| Review resource recommendations and costs | Insights |
| Divide controller ownership by namespace | Multi-tenant scaling |
| Scale workloads across cluster APIs | Multi-cluster scaling |
| Manage installations and inspect scaling health | Operate |
Architecture shows where these components run. For an existing KEDA installation, use the migration guide and production configuration guidance.