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:

    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. kind: ConfigMap
    2. metadata:
    3. name: config-autoscaler
    4. namespace: knative-serving
    5. max-scale: "3"
    6. max-scale-limit: "100"

    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
    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. namespace: knative-serving
    5. initial-scale: "0"
    6. allow-zero-initial-scale: "true"

    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

    Was this page helpful?

    Glad to hear it! Please .