Knative Tutorials: Knative Service: configmap config-autoscaler

container-concurrency-target-default: "100"
target-burst-capacity: "211"
stable-window: "60s"
panic-window-percentage: "10.0"
max-scale-up-rate: "1000.0"
max-scale-down-rate: "2.0"
enable-scale-to-zero: "true"
scale-to-zero-grace-period: "30s"
scale-to-zero-pod-retention-period: "0s"
pod-autoscaler-class: "kpa.autoscaling.knative.dev"
activator-capacity: "100.0"
initial-scale: "1"
allow-zero-initial-scale: "false"
min-scale: "0"
max-scale: "0"
scale-down-delay: "0s"
max-scale-limit: "0"

	[root@int-knd-02-int-awknd2-cloudcontrol-96b182f1df4 serving]# kubectl describe configmap config-autoscaler -n knative-serving
	Name: config-autoscaler
	Namespace: knative-serving
	Labels: app.kubernetes.io/component=autoscaler
	app.kubernetes.io/name=knative-serving
	app.kubernetes.io/version=1.7.4
	Annotations: knative.dev/example-checksum: 47c2487f

	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: "211"

	# 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 (must be positive, but recommended
	# at least a few seconds if running with mesh networking).
	# 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 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"

	# min-scale is the cluster-wide default value for the min scale of a revision,
	# unless overridden by the "autoscaling.knative.dev/minScale" annotation.
	min-scale: "0"

	# 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"


	BinaryData
	====

view raw config-autoscaler.yaml hosted with

by GitHub

Rajesh Kumar

I’m a DevOps/SRE/DevSecOps/Cloud Expert passionate about sharing knowledge and experiences. I am working at Cotocus. I blog tech insights at DevOps School, travel stories at Holiday Landmark, stock market tips at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at I reviewed , and SEO strategies at Wizbrand.

Please find my social handles as below;

Rajesh Kumar Personal Website
Rajesh Kumar at YOUTUBE
Rajesh Kumar at INSTAGRAM
Rajesh Kumar at X
Rajesh Kumar at FACEBOOK
Rajesh Kumar at LINKEDIN
Rajesh Kumar at PINTEREST
Rajesh Kumar at QUORA
Rajesh Kumar at WIZBRAND