Configuring scale bounds

You can configure upper and lower bounds to control autoscaling behavior.

You can also specify the initial scale that a Revision is scaled to immediately after creation. This can be a default configuration for all Revisions, or for a specific Revision using an annotation.

Lower bound

This value controls the minimum number of replicas that each Revision should have. Knative will attempt to never have less than this number of replicas at any one point in time.

  • Global key: n/a
  • Per-revision annotation key: autoscaling.knative.dev/minScale
  • Possible values: integer
  • Default: 0 if scale-to-zero is enabled and class KPA is used, 1 otherwise

NOTE: For more information about scale-to-zero configuration, see the documentation on Configuring scale to zero.

Example:

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: helloworld-go
  5.   namespace: default
  6. spec:
  7.   template:
  8.     metadata:
  9.       annotations:
  10.         autoscaling.knative.dev/minScale: "3"
  11.     spec:
  12.       containers:
  13.         - image: gcr.io/knative-samples/helloworld-go

Upper bound

This value controls the maximum number of replicas that each revision should have. Knative will attempt to never have more than this number of replicas running, or in the process of being created, at any one point in time.

If the max-scale-limit global key is set, Knative ensures that neither the global max scale nor the per-revision max scale for new revisions exceed this value. When max-scale-limit is set to a positive value, a revision with a max scale above that value (including 0, which means unlimited) is disallowed.

  • Global key: max-scale
  • Per-revision annotation key: autoscaling.knative.dev/maxScale
  • Possible values: integer
  • Default: 0 which means unlimited

Example:

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: helloworld-go
  5.   namespace: default
  6. spec:
  7.   template:
  8.     metadata:
  9.       annotations:
  10.         autoscaling.knative.dev/maxScale: "3"
  11.     spec:
  12.       containers:
  13.         - image: gcr.io/knative-samples/helloworld-go
  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: config-autoscaler
  5.   namespace: knative-serving
  6. data:
  7.   max-scale: "3"
  8.   max-scale-limit: "100"
  1. apiVersion: operator.knative.dev/v1alpha1
  2. kind: KnativeServing
  3. metadata:
  4.   name: knative-serving
  5. spec:
  6.   config:
  7.     autoscaler:
  8.       max-scale: "3"
  9.       max-scale-limit: "100"

Initial scale

This value controls the initial target scale a Revision must reach immediately after it is created before it is marked as Ready. After the Revision has reached this scale one time, this value is ignored. This means that the Revision will scale down after the initial target scale is reached if the actual traffic received only needs a smaller scale.

When the Revision is created, the larger of initial scale and lower bound is automatically chosen as the initial target scale.

  • Global key: initial-scale in combination with allow-zero-initial-scale
  • Per-revision annotation key: autoscaling.knative.dev/initialScale
  • Possible values: integer
  • Default: 1

Example:

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: helloworld-go
  5.   namespace: default
  6. spec:
  7.   template:
  8.     metadata:
  9.       annotations:
  10.         autoscaling.knative.dev/initialScale: "0"
  11.     spec:
  12.       containers:
  13.         - image: gcr.io/knative-samples/helloworld-go
  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: config-autoscaler
  5.   namespace: knative-serving
  6. data:
  7.   initial-scale: "0"
  8.   allow-zero-initial-scale: "true"
  1. apiVersion: operator.knative.dev/v1alpha1
  2. kind: KnativeServing
  3. metadata:
  4.   name: knative-serving
  5. spec:
  6.   config:
  7.     autoscaler:
  8.       initial-scale: "0"
  9.       allow-zero-initial-scale: "true"

Scale Down Delay

Scale Down Delay specifies a time window which must pass at reduced concurrency before a scale-down decision is applied. This can be useful, for example, to keep containers around for a configurable duration to avoid a cold start penalty if new requests come in. Unlike setting a lower bound, the revision will eventually be scaled down if reduced concurrency is maintained for the delay period.

  • Global key: scale-down-delay
  • Per-revision annotation key: autoscaling.knative.dev/scaleDownDelay
  • Possible values: Duration, 0s <= value <= 1h
  • Default: 0s (no delay)

Example:

  1. apiVersion: serving.knative.dev/v1
  2. kind: Service
  3. metadata:
  4.   name: helloworld-go
  5.   namespace: default
  6. spec:
  7.   template:
  8.     metadata:
  9.       annotations:
  10.         autoscaling.knative.dev/scaleDownDelay: "15m"
  11.     spec:
  12.       containers:
  13.         - image: gcr.io/knative-samples/helloworld-go
  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: config-autoscaler
  5.   namespace: knative-serving
  6. data:
  7.   scale-down-delay: "15m"
  1. apiVersion: operator.knative.dev/v1alpha1
  2. kind: KnativeServing
  3. metadata:
  4.   name: knative-serving
  5. spec:
  6.   config:
  7.     autoscaler:
  8.       scale-down-delay: "15m"

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.