2.3. 并发


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

  • 软限制是目标请求限制,而不是严格实施的绑定。例如,如果流量突发,可以超过软限制目标。
  • 硬限制是严格实施的上限请求限制。如果并发达到硬限制,则请求将被缓冲,必须等到有足够的可用容量来执行请求。

    重要

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

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

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

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

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

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.