Configuring scale bounds

    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.

    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:
    • 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:

    Per Revision

    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.

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

    Example:

    Per Revision

    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

    Global (ConfigMap)

    1. apiVersion: v1
    2. metadata:
    3. name: config-autoscaler
    4. namespace: knative-serving
    5. max-scale: "3"
    6. max-scale-limit: "100"

    Global (Operator)

    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

    Per Revision

    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

    Global (ConfigMap)

    1. apiVersion: v1
    2. kind: ConfigMap
    3. metadata:
    4. namespace: knative-serving
    5. initial-scale: "0"
    6. allow-zero-initial-scale: "true"

    Global (Operator)

    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:

    Per Revision

    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. scale-down-delay: "15m"

    Global (Operator)