4.2. 自动缩放

4.2.1. 自动缩放

Knative Serving 为应用程序提供自动扩展功能（或 autoscaling），以满足传入的需求。例如，如果应用程序没有流量，并且启用了缩减到零，Knative Serving 将应用程序缩减为零个副本。如果缩减到零，则应用程序会缩减到为集群中的应用程序配置的最小副本数。如果应用流量增加，也可以向上扩展副本来满足需求。

Knative 服务的自动扩展设置可以是由集群管理员配置的全局设置，或为单个服务配置每个修订设置。

您可以使用 OpenShift Container Platform Web 控制台修改服务的每个修订设置，方法是修改服务的 YAML 文件，或使用 Knative (kn) CLI 修改服务。

注意

您为服务设置的任何限制或目标均是针对应用程序的单个实例来衡量。例如，将 target 注解设置为 50 可将自动扩展器配置为缩放应用程序，以便每个修订一次处理 50 个请求。

4.2.2. 扩展范围

缩放范围决定了可在任意给定时间为应用程序服务的最小和最大副本数。您可以为应用设置规模绑定，以帮助防止冷启动和控制计算成本。

4.2.2.1. 最小扩展范围

为应用程序提供服务的最小副本数量由 min-scale 注解决定。如果没有启用缩减为零，则 min-scale 值默认为 1。

如果满足以下条件，min-scale 值默认为 0 个副本：

  • 不设置 min-scale 注解
  • 启用扩展到零
  • 使用类 KPA

带有 min-scale 注解的 service spec 示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/min-scale: "0"
...

4.2.2.1.1. 使用 Knative CLI 设置 min-scale 注解

使用 Knative (kn) CLI 设置 min-scale 注解，比直接修改 YAML 文件提供了一个更加精简且直观的用户界面。您可以使用带有 --scale-min 标志的 kn service 命令为服务创建或修改 min-scale 值。

先决条件

  • 在集群中安装了 Knative Serving。
  • 已安装 Knative (kn) CLI。

流程

  • 使用 --scale-min 标志设置服务的最小副本数： 

    $ kn service create <service_name> --image <image_uri> --scale-min <integer>

    示例命令

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-min 2

4.2.2.2. 最大扩展范围

可提供应用程序的副本数量由 max-scale 注解决定。如果没有设置 max-scale 注解，则创建的副本数没有上限。

带有 max-scale 注解的 service spec 示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/max-scale: "10"
...

4.2.2.2.1. 使用 Knative CLI 设置 max-scale 注解

使用 Knative (kn) CLI 设置 max-scale 注解，比直接修改 YAML 文件提供了一个更精简且直观的用户界面。您可以使用带有 --scale-max 标志的 kn service 命令为服务创建或修改 max-scale 值。

先决条件

  • 在集群中安装了 Knative Serving。
  • 已安装 Knative (kn) CLI。

流程

  • 使用 --scale-max 标志设置服务的最大副本数： 

    $ kn service create <service_name> --image <image_uri> --scale-max <integer>

    示例命令

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --scale-max 10

4.2.3. 并发

并发请求数决定了应用程序的每个副本可在任意给定时间处理的并发请求数。并发可以配置为软限制或硬限制 ：

  • 软限制是目标请求限制，而不是严格实施的绑定。例如，如果流量突发，可以超过软限制目标。

  • 硬限制是严格实施的上限请求限制。如果并发达到硬限制，则请求将被缓冲，必须等到有足够的可用容量来执行请求。

    重要

    只有在应用程序中明确用例时才建议使用硬限制配置。指定较少的硬限制可能会对应用程序的吞吐量和延迟造成负面影响，并可能导致冷启动。

添加软目标和硬限制意味着自动扩展以并发请求的软目标数为目标，但为请求的最大数量施加硬限制值。

如果硬限制值小于软限制值，则软限制值将降级，因为不需要将目标设定为多于实际处理的请求数。

4.2.3.1. 配置软并发目标

软限制是目标请求限制，而不是严格实施的绑定。例如，如果流量突发，可以超过软限制目标。您可以通过在 spec 中设置 autoscaling.knative.dev/target 注解，或者使用带有正确标记的 kn service 命令为 Knative 服务指定软并发目标。

流程

  • 可选：在 Service 自定义资源的 spec 中为您的 Knative 服务设置 autoscaling.knative.dev/target 注解：

    服务规格示例

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target: "200"

  • 可选： 使用 kn service 命令指定 --concurrency-target 标志： 

    $ kn service create <service_name> --image <image_uri> --concurrency-target <integer>

    创建服务的示例，并发目标为 50 请求

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-target 50

4.2.3.2. 配置硬并发限制

硬并发限制是严格强制执行上限的上限。如果并发达到硬限制，则请求将被缓冲，必须等到有足够的可用容量来执行请求。您可以通过修改 containerConcurrency spec 或使用带有正确标记的 kn service 命令为 Knative 服务指定硬并发限制。

流程

  • 可选：在 Service 自定义资源的 spec 中为您的 Knative 服务设置 containerConcurrency spec：

    服务规格示例

    apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    spec:
      containerConcurrency: 50

    默认值为 0，这意味着允许同时访问服务的一个副本的请求数量没有限制。

    大于 0 的值指定允许一次传输到服务的一个副本的请求的确切数量。这个示例将启用 50 个请求的硬并发限制。

  • 可选： 使用 kn service 命令指定 --concurrency-limit 标志： 

    $ kn service create <service_name> --image <image_uri> --concurrency-limit <integer>

    创建服务且并发限制为 50 个请求的命令示例

    $ kn service create example-service --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest --concurrency-limit 50

4.2.3.3. 并发目标使用率

此值指定自动扩展实际的目标并发限制的百分比。这也称为指定运行副本的热性（hotness），允许自动扩展在达到定义的硬限制前进行扩展。

例如，如果 containerConcurrency 值设置为 10，并且 target-utilization-percentage 值设置为 70%，则自动扩展会在所有现有副本的平均并发请求数量达到 7 时创建一个新的副本。编号为 7 到 10 的请求仍然会被发送到现有的副本，但达到 containerConcurrency 值后会启动额外的副本。

使用 target-utilization-percentage 注解配置的服务示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: example-service
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
...

4.2.4. Scale-to-zero

Knative Serving 为应用程序提供自动扩展功能（或 autoscaling），以满足传入的需求。

4.2.4.1. 启用 scale-to-zero

您可以使用 enable-scale-to-zero spec，为集群中的应用程序全局启用或禁用 scale-to-zero。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 有集群管理员权限。
  • 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler，则缩减为零功能将不可用。

流程

  • 在 KnativeServing 自定义资源 (CR) 中修改 enable-scale-to-zero spec：

    KnativeServing CR 示例

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    autoscaler:
      enable-scale-to-zero: "false" 1

    1
    enable-scale-to-zero spec 可以是 "true" 或 "false"。如果设置为 true，则会启用 scale-to-zero。如果设置为 false，应用程序将缩减至配置的最小扩展绑定。默认值为 "true"。

4.2.4.2. 配置 scale-to-zero 宽限期

Knative Serving 为应用程序提供自动缩放为零个 pod。您可以使用 scale-to-zero-grace-period spec 定义上限，Knative 在删除应用程序的最后一个副本前等待 scale-to-zero machinery 原位。

先决条件

  • 在集群中安装了 OpenShift Serverless Operator 和 Knative Serving。
  • 有集群管理员权限。
  • 使用默认的 Knative Pod Autoscaler。如果使用 Kubernetes Horizontal Pod Autoscaler，则缩减为零功能将不可用。

流程

  • 在 KnativeServing 自定义资源 (CR) 中修改 scale-to-zero-grace-period spec：

    KnativeServing CR 示例

    apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    autoscaler:
      scale-to-zero-grace-period: "30s" 1

    1
    宽限期（以秒为单位）。默认值为 30 秒。