Document usage recommendations and considerations (scale from 1)

[muscionig]

This issue tracks recommendations and considerations when using the autoscaler-keda plugin. Most of these points are summarized from the following conversation: Slack discussion.

Context

The autoscaler-keda plugin creates ScaledObjects to manage the scaling of Knative services. Each revision of a Knative service gets its own ScaledObject, which is versioned accordingly.

---

Considerations & Recommendations

1. Availability of Metrics for Scaling

   • The metrics defined in the PrometheusQuery must be available for scaling to occur.
   • If the metric originates from the service itself, at least one replica must remain active to provide the necessary data.

2. Behavior of ScaledObjects with New Revisions

   • ScaledObjects persist even after a new revision is created. If a metric triggers scaling, multiple revisions can scale up simultaneously, even if traffic routing is configured to target only the latest revision.

3. Disabling ScaledObjects and Traffic Splitting

   • While KEDA supports disabling ScaledObjects, this is not a viable option for Knative services that require traffic splitting across revisions. Traffic splitting mandates that all relevant ScaledObjects remain functional.

4. Injecting Revision Names in Prometheus Queries

   • If RevisionName templating and substitution. #84 is merged, autoscaler-keda will support injecting revision names into Prometheus queries.
   • However, since Knative allows users to define their own revision names, this feature may still result in the scaling issues described in point 3. See discussion RevisionName templating and substitution. #84 (comment).

5. Traffic Splitting and Metrics for Scale-Up

   • Metrics used for scaling, such as http_request_total, should account for traffic splitting:
     • A common metric could be used with proportional scaling applied to each revision based on its traffic share.
     • Alternatively, a label could be injected into the metric to differentiate revisions.

6. Handling Substitutions in Prometheus Queries

   • Currently, RevisionName templating and substitution. #84 implements substitutions only for the main Prometheus query.
   • If additional triggers are defined, this substitution mechanism could be extended to support them as well.

@skonto feel free to add/remove items. I'll log another issue for the scale from zero use case soon.