Decouple autoscaling configuration from KSvc/Revisions/ConfigMap

[julz]

Problem

Right now if I want to customise my autoscaling properties (target, initialScale, containerConcurrency, burst capacity etc) I have to either do it independently for each ksvc/revision (understanding all the various knobs) or hope my cluster administrator made good default choices. Which is sometimes ok - cluster admins are nice and smart people. But! They can only specify global defaults. For a cluster that has a number of single-threaded event-style apps and a number of multi-threaded web-style apps that means our defaults can only easily be tuned for one or the other case, which is sad and leads to more people needing to fully grok autoscaler knobs than would be ideal.

It also makes it difficult to have different defaults per-namespace, which is a pretty reasonable thing to want, or to tweak defaults for a series of related services in one place.

One Possible Solution:

An AutoscalerClass CRD, similar to native kubernetes IngressClass, allowing defining a named autoscaler controller and associated configuration. For example:

apiVersion: autoscaling.knative.dev/v1alpha1
kind: AutoscalerClass
metadata:
  name: webapp
spec:
  controller: autoscaling.knative.dev/kpa
  parameters:
    target: 70
    concurrency: 0
----
apiVersion: autoscaling.knative.dev/v1alpha1
kind: AutoscalerClass
metadata:
  name: function
spec:
  controller: autoscaling.knative.dev/kpa
  parameters:
    target: 90
    concurrency: 1

I could then ask for the given class in the same way as today I choose kpa or hpa. (You could still override those defaults per-ksvc/revision). A potential extension of this would be to support setting a per-namespace default AutoscalerClass.

I'm not actually sure this is a good idea but.. seems worth a conversation :)

[vagababov]

I had similar concerns as well, but didn't think much along the solutions, so thanks for that! :)

One way I looked at it profiles in the cli/ui, where you can specify canned configurations and CLI/UI knows how to apply them when you specify class=webapp. Probably also less work codewise :-)

[jchesterpivotal]

I'm a fan of this change. I got reader feedback that the mix of ConfigMaps and annotations was very confusing.

[mattmoor]

FWIW, I like the name profiles.

[julz]

@mattmoor me too, "Profiles" sounds good, although I think we now see this as an extension of https://github.com/knative/serving/issues/8114 (tho part of me now sort-of thinks it might be a shame to block the lowish-hanging fruit of a Profile for autoscaling on the larger scale move of all the config maps to CRDs 🤔).

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[vagababov]

/reopen

[knative-prow-robot]

@vagababov: Reopened this issue.

In response to [this](https://github.com/knative/serving/issues/7711#issuecomment-747190649): >/reopen Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[vagababov]

/assign @julz

I think Julian wanted this.

[evankanderson]

/area API

/assign @julz

/triage accepted

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen the issue with /reopen. Mark the issue as fresh by adding the comment /remove-lifecycle stale.

[dprotaso]

/unassign @julz