# Copyright 2018 The Knative Authors
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config-autoscaler
  namespace: knative-serving
  labels:
    serving.knative.dev/release: "v0.19.0"
  annotations:
    knative.dev/example-checksum: "1d830d9e"
data:
  _example: |
    ################################
    #                              #
    #    EXAMPLE CONFIGURATION     #
    #                              #
    ################################

    # This block is not actually functional configuration,
    # but serves to illustrate the available configuration
    # options and document them in a way that is accessible
    # to users that `kubectl edit` this config map.
    #
    # These sample configuration options may be copied out of
    # this example block and unindented to be in the data block
    # to actually change the configuration.

    # The Revision ContainerConcurrency field specifies the maximum number
    # of requests the Container can handle at once. Container concurrency
    # target percentage is how much of that maximum to use in a stable
    # state. E.g. if a Revision specifies ContainerConcurrency of 10, then
    # the Autoscaler will try to maintain 7 concurrent connections per pod
    # on average.
    # Note: this limit will be applied to container concurrency set at every
    # level (ConfigMap, Revision Spec or Annotation).
    # For legacy and backwards compatibility reasons, this value also accepts
    # fractional values in (0, 1] interval (i.e. 0.7 ⇒ 70%).
    # Thus minimal percentage value must be greater than 1.0, or it will be
    # treated as a fraction.
    # NOTE: that this value does not affect actual number of concurrent requests
    #       the user container may receive, but only the average number of requests
    #       that the revision pods will receive.
    container-concurrency-target-percentage: "70"

    # The container concurrency target default is what the Autoscaler will
    # try to maintain when concurrency is used as the scaling metric for the
    # Revision and the Revision specifies unlimited concurrency.
    # When revision explicitly specifies container concurrency, that value
    # will be used as a scaling target for autoscaler.
    # When specifying unlimited concurrency, the autoscaler will
    # horizontally scale the application based on this target concurrency.
    # This is what we call "soft limit" in the documentation, i.e. it only
    # affects number of pods and does not affect the number of requests
    # individual pod processes.
    # The value must be a positive number such that the value multiplied
    # by container-concurrency-target-percentage is greater than 0.01.
    # NOTE: that this value will be adjusted by application of
    #       container-concurrency-target-percentage, i.e. by default
    #       the system will target on average 70 concurrent requests
    #       per revision pod.
    # NOTE: Only one metric can be used for autoscaling a Revision.
    container-concurrency-target-default: "100"

    # The requests per second (RPS) target default is what the Autoscaler will
    # try to maintain when RPS is used as the scaling metric for a Revision and
    # the Revision specifies unlimited RPS. Even when specifying unlimited RPS,
    # the autoscaler will horizontally scale the application based on this
    # target RPS.
    # Must be greater than 1.0.
    # NOTE: Only one metric can be used for autoscaling a Revision.
    requests-per-second-target-default: "200"

    # The target burst capacity specifies the size of burst in concurrent
    # requests that the system operator expects the system will receive.
    # Autoscaler will try to protect the system from queueing by introducing
    # Activator in the request path if the current spare capacity of the
    # service is less than this setting.
    # If this setting is 0, then Activator will be in the request path only
    # when the revision is scaled to 0.
    # If this setting is > 0 and container-concurrency-target-percentage is
    # 100% or 1.0, then activator will always be in the request path.
    # -1 denotes unlimited target-burst-capacity and activator will always
    # be in the request path.
    # Other negative values are invalid.
    target-burst-capacity: "200"

    # When operating in a stable mode, the autoscaler operates on the
    # average concurrency over the stable window.
    # Stable window must be in whole seconds.
    stable-window: "60s"

    # When observed average concurrency during the panic window reaches
    # panic-threshold-percentage the target concurrency, the autoscaler
    # enters panic mode. When operating in panic mode, the autoscaler
    # scales on the average concurrency over the panic window which is
    # panic-window-percentage of the stable-window.
    # Must be in the [1, 100] range.
    # When computing the panic window it will be rounded to the closest
    # whole second, at least 1s.
    panic-window-percentage: "10.0"

    # The percentage of the container concurrency target at which to
    # enter panic mode when reached within the panic window.
    panic-threshold-percentage: "200.0"

    # Max scale up rate limits the rate at which the autoscaler will
    # increase pod count. It is the maximum ratio of desired pods versus
    # observed pods.
    # Cannot be less or equal to 1.
    # I.e with value of 2.0 the number of pods can at most go N to 2N
    # over single Autoscaler period (2s), but at least N to
    # N+1, if Autoscaler needs to scale up.
    max-scale-up-rate: "1000.0"

    # Max scale down rate limits the rate at which the autoscaler will
    # decrease pod count. It is the maximum ratio of observed pods versus
    # desired pods.
    # Cannot be less or equal to 1.
    # I.e. with value of 2.0 the number of pods can at most go N to N/2
    # over single Autoscaler evaluation period (2s), but at
    # least N to N-1, if Autoscaler needs to scale down.
    max-scale-down-rate: "2.0"

    # Scale to zero feature flag.
    enable-scale-to-zero: "true"

    # Scale to zero grace period is the time an inactive revision is left
    # running before it is scaled to zero (min: 6s).
    # This is the upper limit and is provided not to enforce timeout after
    # the revision stopped receiving requests for stable window, but to
    # ensure network reprogramming to put activator in the path has completed.
    # If the system determines that a shorter period is satisfactory,
    # then the system will only wait that amount of time before scaling to 0.
    # NOTE: this period might actually be 0, if activator has been
    # in the request path sufficiently long.
    # If there is necessity for the last pod to linger longer use
    # scale-to-zero-pod-retention-period flag.
    scale-to-zero-grace-period: "30s"

    # Scale to zero pod retention period defines the minimum amount
    # of time the last pod will remain after Autoscaler has decided to
    # scale to zero.
    # This flag is for the situations where the pod startup is very expensive
    # and the traffic is bursty (requiring smaller windows for fast action),
    # but patchy.
    # The larger of this flag and `scale-to-zero-grace-period` will effectively
    # determine how the last pod will hang around.
    scale-to-zero-pod-retention-period: "0s"

    # pod-autoscaler-class specifies the default pod autoscaler class
    # that should be used if none is specified. If omitted, the Knative
    # Horizontal Pod Autoscaler (KPA) is used by default.
    pod-autoscaler-class: "kpa.autoscaling.knative.dev"

    # The capacity of a single activator task.
    # The `unit` is one concurrent request proxied by the activator.
    # activator-capacity must be at least 1.
    # This value is used for computation of the Activator subset size.
    # See the algorithm here: http://bit.ly/38XiCZ3.
    # TODO(vagababov): tune after actual benchmarking.
    activator-capacity: "100.0"

    # initial-scale is the cluster-wide default value for the initial target
    # scale of a revision after creation, unless overridden by the
    # "autoscaling.knative.dev/initialScale" annotation.
    # This value must be greater than 0 unless allow-zero-initial-scale is true.
    initial-scale: "1"

    # allow-zero-initial-scale controls whether either the cluster-wide initial-scale flag,
    # or the "autoscaling.knative.dev/initialScale" annotation, can be set to 0.
    allow-zero-initial-scale: "false"

    # max-scale is the cluster-wide default value for the max scale of a revision,
    # unless overridden by the "autoscaling.knative.dev/maxScale" annotation.
    # If set to 0, the revision has no maximum scale.
    max-scale: "0"

    # scale-down-delay is the amount of time that must pass at reduced
    # concurrency before a scale down decision is applied. This can be useful,
    # for example, to maintain replica count and avoid a cold start penalty if
    # more requests come in within the scale down delay period.
    # The default, 0s, imposes no delay at all.
    scale-down-delay: "0s"

    # max-scale-limit sets the maximum permitted value for the max scale of a revision.
    # When this is set to a positive value, a revision with a maxScale above that value
    # (including a maxScale of "0" = unlimited) is disallowed.
    # A value of zero (the default) allows any limit, including unlimited.
    max-scale-limit: "0"
