Problem statement:

Today, developers can pick a number of minimum replicas, however:

• any update to this setting results in the full deployment of a new revision.
• it is a revision-level setting, meaning that if multiple revisions are serving traffic, the number of total min replicas depends on how many revisions are serving.

Suggested feature

Introduce a new "minScale" annotation at the service level, which applies to all revisions of the service.

Use cases

Allows to dynamically control the number of minimum replicas of a Knative service, which is useful when:

• anticipating an event that will result in a traffic spike and want to pre-warm replicas
• automating min replicas allocation (e.g. 0 during the night, N during the day)
• wanting to reserve some capacity for a service within the cluster

API

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
  annotations:
   autoscaling.knative.dev/minScale: '100'
spec:
  template:
    annotations:
     autoscaling.knative.dev/minScale: '10'
    spec:
      container:
        image: …

Relationship with per-revision minScale

Min replicas are allocated first from Service-level minScale. Then, if the Revision-level minScale is higher than the allocated number, the revision gets the higher number of min replicas.

E.g. if Service-level specifies 20 min-replicas, and splits traffic at 50/50 between Revision A and Revision B. If Revision A specifies 15 minScale, then:

• Revision A gets 15
• Revision B gets 10

Additional notes

Cloud Run, which aims at portability with Knative serving, is introducing this feature using a vendor extension. Cloud Run would switch to using the Knative spec if Knative defined and implemented this behavior.

/area API
/area autoscale
/kind spec