Capability availability and enablement
Availability depends on the installed component set and enabled capabilities. A chart flag, a controller, a telemetry path and a hosted feature are different prerequisites. Independent latest tags on the versions page do not establish a tested bundle.
Capability prerequisites and enablement
Section titled “Capability prerequisites and enablement”| Area | Required component or evidence | Enable/configure owner |
|---|---|---|
| Event-driven replicas/jobs | KEDA and the selected source/authentication path | Built-in scalers |
| HTTP and zero activation | Kedify KEDA, HTTP components, Agent/proxy integration and working route | HTTP scaling |
| Existing Envoy metrics | Compatible Kedify trigger and configured metrics sink; no zero activation | Existing Envoy |
| OTel metrics | OTel add-on and selected export/collector pipeline | OTel setup |
| PRP | Agent PRP controller, target opt-in where configured, in-place resize support | PRP enablement |
| PRA | Agent PRA controller, metric/resize permissions and supported resize | PRA enablement |
| Insights | Connected Agent; Agent v0.7.0 or later; selected namespace utilization and Metrics API | Insights settings |
| FinOps | Collected capacity plus provider/pricing metadata for spend estimates | FinOps interpretation |
| Prediction | Predictor/controller, history store and useful training data | Predictor enablement |
| Fleet visibility | Separate connected installation identity per cluster | Cluster connection |
| Distributed replicas/jobs | Agent distributed controllers, registered member access; jobs also need KEDA raw metrics | Distributed scaling |
| vCluster | Supported central/virtual topology and API discovery/access | vCluster procedure |
| Tenant KEDA/KPA | Compatible paired releases, non-overlapping namespace scope and shared CRD ownership | Tenant installation |
| ScalingPolicy / timed resume | Applicable Agent controllers and target ownership | Policy · Maintenance |
| ScalingGroup | Kedify KEDA group controller; documented HPA/metric restrictions | Scaling Groups |
| ScaleAdapter / node buffers | Enabled adapter, target permissions and provider-specific capacity support | Custom targets · Node capacity |
| Inference | Documented routing/InferencePool or vLLM metric scenario, model readiness and device capacity | HTTP inference setup |
| Health checks, HTTP logs and traces | Their emitting components and configured collection path | Observation |
| Private registry | Mirrored release images, pull credentials and applicable service connectivity | Private registry install |
| Security evidence | Applicable image/host/deployment scope and release evidence | Security and compliance |
Version and default provenance
Section titled “Version and default provenance”Helm values records chart-scoped defaults from the inspected Agent v0.7.0 snapshot and preserves newer documented feature paths separately. Collection flags do not install KPA or every monitored component. KPA’s current documentation scopes Kubernetes support to 1.33–1.35; verify the paired KEDA/Agent/KPA bundle before rollout. In-place resize requirements apply independently of the Agent chart’s broad Kubernetes install constraint.
Use kubectl get crd <crd-name> -o yaml to compare the installed fields with the API reference. A CRD being present does not prove its controller is enabled or owns the target namespace.
Before enabling a capability
Section titled “Before enabling a capability”Record installed versions and the configuration owner, verify the linked prerequisites, then enable one bounded workload and inspect its expected outcome. Confirm support and account availability for the intended component combination with your release/installation owner before production changes. Use Kedify capabilities to select a benefit rather than enabling flags merely because they exist.