此内容没有您所选择的语言版本。
Chapter 7. Configuring Knative Serving autoscaling
OpenShift Serverless provides capabilities for automatic Pod scaling, including scaling inactive Pods to zero, by enabling the Knative Serving autoscaling system in an OpenShift Container Platform cluster.
To enable autoscaling for Knative Serving, you must configure concurrency and scale bounds in the revision template.
Any limits or targets set in the revision template are measured against a single instance of your application. For example, setting the target
annotation to 50
will configure the autoscaler to scale the application so that each instance of it will handle 50 requests at a time.
7.1. Configuring concurrent requests for Knative Serving autoscaling
You can specify the number of concurrent requests that should be handled by each instance of an application (revision container) by adding the target
annotation or the containerConcurrency
field in the revision template.
Here is an example of target
being used in a revision template:
apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: myapp spec: template: metadata: annotations: autoscaling.knative.dev/target: 50 spec: containers: - image: myimage
Here is an example of containerConcurrency
being used in a revision template:
apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: myapp spec: template: metadata: annotations: spec: containerConcurrency: 100 containers: - image: myimage
Adding a value for both target
and containerConcurrency
will target the target
number of concurrent requests, but impose a hard limit of the containerConcurrency
number of requests.
For example, if the target
value is 50 and the containerConcurrency
value is 100, the targeted number of requests will be 50, but the hard limit will be 100.
If the containerConcurrency
value is less than the target
value, the target
value will be tuned down, since there is no need to target more requests than the number that can actually be handled.
containerConcurrency
should only be used if there is a clear need to limit how many requests reach the application at a given time. Using containerConcurrency
is only advised if the application needs to have an enforced constraint of concurrency.
7.1.1. Configuring concurrent requests using the target annotation
The default target for the number of concurrent requests is 100
, but you can override this value by adding or modifying the autoscaling.knative.dev/target
annotation value in the revision template.
Here is an example of how this annotation is used in the revision template to set the target to 50
.
autoscaling.knative.dev/target: 50
7.1.2. Configuring concurrent requests using the containerConcurrency field
containerConcurrency
sets a hard limit on the number of concurrent requests handled.
containerConcurrency: 0 | 1 | 2-N
- 0
- allows unlimited concurrent requests.
- 1
- guarantees that only one request is handled at a time by a given instance of the revision container.
- 2 or more
- will limit request concurrency to that value.
If there is no target
annotation, autoscaling is configured as if target
is equal to the value of containerConcurrency
.
7.2. Configuring scale bounds Knative Serving autoscaling
The minScale
and maxScale
annotations can be used to configure the minimum and maximum number of Pods that can serve applications. These annotations can be used to prevent cold starts or to help control computing costs.
- minScale
-
If the
minScale
annotation is not set, Pods will scale to zero (or to 1 if enable-scale-to-zero is false per theConfigMap
). - maxScale
-
If the
maxScale
annotation is not set, there will be no upper limit for the number of Pods created.
minScale
and maxScale
can be configured as follows in the revision template:
spec: template: metadata: autoscaling.knative.dev/minScale: "2" autoscaling.knative.dev/maxScale: "10"
Using these annotations in the revision template will propagate this confguration to PodAutoscaler
objects.
These annotations apply for the full lifetime of a revision. Even when a revision is not referenced by any route, the minimal Pod count specified by minScale
will still be provided. Keep in mind that non-routeable revisions may be garbage collected, which enables Knative to reclaim the resources.