Knative 是一款基于 Kubernetes 的开源 Serverless 应用编排框架，其目标是制定云原生、跨平台的 Serverless 应用编排标准。Knative 主要功能包括基于请求的自动弹性、缩容到 0、多版本管理、基于流量的灰度发布以及事件驱动等。

弹性是 Serverless 中的核心能力，那么 Knative 作为 CNCF 社区最受欢迎的开源 Serverless 应用框架，提供了哪些与众不同的弹性能力呢？本文将带你深入了解 Knative 的弹性实现。（说明：本文基于 Knative 1.8.0 版本进行分析）

Knative 提供了基于请求的自动弹性实现 KPA（Knative Pod Autoscaler），也支持 K8s 中的 HPA，此外 Knative 提供了灵活的弹性扩展机制，可以结合自身业务需要，扩展弹性实现。这里我们也会介绍与 MSE 结合实现精准弹性以及与 AHPA 结合实现基于请求的弹性预测。

首先我们介绍 Knative 原生最具吸引力的弹性：KPA。

基于请求的自动弹性 KPA

基于 CPU 或者 Memory 的弹性，有时候并不能完全反映业务的真实使用情况，而基于并发数或者每秒处理请求数 (QPS/RPS)，对于 web 服务来说更能直接反映服务性能，Knative 提供了基于请求的自动弹性能力。要获得当前服务的请求数，Knative Serving 为每个 Pod 注入 QUEUE 代理容器 (queue-proxy)，该容器负责收集用户容器并发数 (concurrency) 或请求数 (rps) 指标。Autoscaler 定时获取这些指标之后，会根据相应的算法，调整 Deployment 的 Pod 数量，从而实现基于请求的自动扩缩容。

图片来源：https://knative.dev/docs/serving/request-flow/

基于请求数的弹性算法

Autoscaler 基于每个 Pod 的平均请求数（或并发数）进行弹性计算。默认情况下 Knative 使用基于并发数的自动弹性, 默认 Pod 的最大并发数为 100。此外 Knative 中还提供了一个叫 target-utilization-percentage 的概念，称之为目标使用率，取值范围 0～1，默认是 :0.7。

以基于并发数弹性为例，Pod 数计算方式如下：

POD数=并发请求总数/(Pod最大并发数*目标使用率)

例如服务中 Pod 最大并发数设置了 10，这时候如果接收到了 100 个并发请求，目标使用率设置为 0.7，那么 Autoscaler 就会创建了 15 个 POD(100/(0.7*10) 约等于 15）。

缩容到 0 的实现机制

使用 KPA 时当无流量请求时，会将 Pod 数自动缩容到 0；当有请求时，会从 0 开始扩容 Pod。那么 Knative 中是如何实现这样的操作呢？答案是通过模式切换。

Knative 中定义了 2 种请求访问模式：Proxy 和 Serve。Proxy 顾名思义，代理模式，也就是请求会通过 activator 组件进行代理转发。Serve 模式是请求直达模式，从网关直接请求到 Pod，不经过 activator 代理。如下图：

模式的切换是由 autoscaler 组件负责，当请求为 0 时，autoscaler 会将请求模式切换为 Proxy 模式。这时候请求会通过网关请求到 activator 组件，activator 收到请求之后会将请求放在队列中，同时推送指标通知 autoscaler 进行扩容，当 activator 检测到由扩容 Ready 的 Pod 之后，随即将请求进行转发。而 autoscaler 也会判断 Ready 的 Pod，将模式切换为 Serve 模式。

应对突发流量

突发流量下如何快速弹资源

KPA 涉及到 2 个与弹性相关的概念：Stable（稳定模式）和 Panic（恐慌模式），基于这 2 种模式，可以让我们认识到 KPA 如何基于请求做到精细化弹性。

首先稳定模式是基于稳定窗口期，默认是 60 秒。也就是计算在 60 秒时间段内，Pod 的平均并发数。

而恐慌模式是基于恐慌窗口期，恐慌窗口期是通过稳定窗口期与 panic-window-percentage 参数计算得到。panic-window-percentage取值是 0～1，默认是 0.1。恐慌窗口期计算方式：恐慌窗口期=稳定窗口期 *panic-window-percentage。默认情况下也就是 6 秒。计算在 6 秒时间段内，Pod 的平均并发数。

KPA 中会基于稳定模式和恐慌模式 Pod 的平均并发数分别计算所需要的 Pod 数。

那么实际根据哪个值进行弹性生效呢？这里会依据恐慌模式下计算的 Pod 数是否超过恐慌阈值 PanicThreshold 进行判断。恐慌阈值是通过 panic-threshold-percentage/100 计算出来，panic-threshold-percentage 参数默认是 200，也就是恐慌阈值默认是 2。当恐慌模式下计算出来的 Pod 数大于或等于当前 Ready Pod 数的 2 倍，那么就会使用恐慌模式 Pod 数进行弹性生效，否则使用稳定模式 Pod 数。

显然，恐慌模式的设计是为了应对突发流量场景。至于弹性敏感度，则可以通过上述的可配置参数进行调节。

突发流量下如何避免 Pod 被打爆

KPA 中可以设置突发请求容量（target-burst-capacity）应对 Pod 被超预期的流量打爆。也就是通过这个参数值的计算，来调节请求是否切换到 Proxy 模式，从而通过 activator 组件作为请求缓冲区。如果当前 ready pod 数*最大并发数-突发请求容量-恐慌模式计算出来的并发数 <0，意味着突发流量超过了容量阈值，则切换到 activator 进行请求缓冲。当突发请求容量值为 0 时，只有 Pod 缩容到 0 时，才切换到 activator。当大于 0 并且 container-concurrency-target-percentage 设置为 100 时，请求总是会通过 activator。-1 表示无限的请求突发容量。请求也总是会通过 activator。

减少冷启动的一些技巧

延迟缩容

对于启动成本较高的 Pod， KPA 中可以通过设置 Pod 延迟缩容时间以及 Pod 缩容到 0 保留期，来减少 Pod 扩缩容频率。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/scale-down-delay: ""60s"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

调低目标使用率，实现资源预热

Knative 中提供了目标阈值使用率的配置。通过调小该值可以提前扩容超过实际需要使用量的 Pod 数，在请求达到目标并发数之前进行扩容，间接的可以做到资源预热。例如，如果 containerConcurrency 设置为 10，目标利用率值设置为 70（百分比），则当所有现有 Pod 的平均并发请求数达到 7 时，Autoscaler 将创建一个新 Pod。因为 Pod 从创建到 Ready 需要一定的时间，通过调低目标利用率值可以做到提前扩容 Pod，从而减少冷启动导致的响应延迟等问题。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/target-utilization-percentage: "70"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:73fbdd56

配置 KPA

通过上面的介绍，我们对 Knative Pod Autoscaler 工作机制有了进一步的了解，那么接下来介绍如何配置 KPA。Knative 中配置 KPA 提供了两种方式：全局模式和 Revision 模式。

全局模式

全局模式可以修改 K8s 中的 ConfigMap：config-autoscaler，查看 config-autoscaler 使用如下命令：

kubectl -n knative-serving get cm config-autoscaler

apiVersion: v1
kind: ConfigMap
metadata:
 name: config-autoscaler
 namespace: knative-serving
data:
 container-concurrency-target-default: "100"
 container-concurrency-target-percentage: "70"
 requests-per-second-target-default: "200"
 target-burst-capacity: "211"
 stable-window: "60s"
 panic-window-percentage: "10.0"
 panic-threshold-percentage: "200.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"

参数说明：

Revision 版本模式

在 Knative 中可以为每一个 Revision 配置弹性指标，部分配置参数如下:

• 指标类型
  • 每个 revision 指标注解：autoscaling.knative.dev/metric
  • 支持的指标："concurrency"，"rps"，"cpu"，"memory"以及其它自定义指标
  • 默认指标："concurrency"
• 目标阈值
  • autoscaling.knative.dev/target
  • 默认值："100"
• pod 缩容到 0 保留期
  • autoscaling.knative.dev/scale-to-zero-pod-retention-period
• 目标使用率
  • autoscaling.knative.dev/target-utilization-percentage

配置示例如下：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/metric: "concurrency"
        autoscaling.knative.dev/target: "50"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "1m5s"
        autoscaling.knative.dev/target-utilization-percentage: "80"

对 HPA 的支持

对于 K8s HPA， Knative 也提供天然的配置支持，可以在 Knative 使用基于 CPU 或者 Memory 的自动弹性能力。

• 基于 CPU 弹性配置

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"

• 基于 Memory 的弹性配置

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "memory"

弹性能力增强

Knative 提供了灵活的插件机制（pod-autoscaler-class），可以支持不同的弹性策略。阿里云容器服务 Knative 当前支持的弹性插件包括：kpa、hpa、精准弹性扩缩容 mpa 以及 具有预测能力的 ahpa。

保留资源池

在原生的 KPA 能力之上，我们提供了保留资源池的能力。该功能可以应用在如下场景：

• ECS 与 ECI 混用。如果希望常态情况下使用 ECS 资源，突发流量使用 ECI， 那么我们可以通过保留资源池来实现。如单个 Pod 处理的并发 10，保留资源池 Pod 数为 5，那么常态下通过 ECS 资源可以应对不超过 50 的并发请求。如果并发数超过 50，那么 Knative 就会扩容新的 Pod 数来满足需求，新扩容出来的资源使用 ECI。

• 资源预热。对于完全使用 ECI 的场景，也可以通过保留资源池实现资源预热。当在业务波谷时使用保留实例替换默认的计算型实例，当第一个请求来临时使用保留实例提供服务，同时也会触发默认规格实例的扩容。当默认规格实例扩容完成以后所有新请求就会都转发到默认规格上，同时保留实例则不会接受新的请求，并且等保留实例所有接收到的请求处理完成以后就会被下线。通过这种无缝替换的方式实现了成本和效率的平衡，即降低了常驻实例的成本又不会有显著的冷启动时长。

精准弹性扩缩容

单个 Pod 处理请求的吞吐率有限，如果多个请求转发到同一个 Pod，会导致服务端过载异常，因此需要精准的控制单个 Pod 请求并发处理数。尤其对一些 AIGC 场景下，单个请求会占用较多的 GPU 资源，需要严格的限制每个 Pod 并发处理的请求数。

Knative 与 MSE 云原生网关结合，提供基于并发数精准控制弹性的实现：mpa 弹性插件。

mpa 会从 MSE 网关获取并发数，并计算所需要的 Pod 数进行扩缩容，而 MSE 网关可以做到基于请求精准转发。

配置示例如下：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld-go
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/class: mpa.autoscaling.knative.dev
        autoscaling.knative.dev/max-scale: '20'
    spec:
      containerConcurrency: 5
      containers:
      - image: registry-vpc.cn-beijing.aliyuncs.com/knative-sample/helloworld-go:73fbdd56
        env:
        - name: TARGET
          value: "Knative"

参数说明：

弹性预测 AHPA

容器服务 AHPA（Advanced Horizontal Pod Autoscaler）可以根据业务历史指标，自动识别弹性周期并对容量进行预测，解决弹性滞后的问题。

当前 Knative 支持 AHPA（Advanced Horizontal Pod Autoscaler）的弹性能力，当请求具有周期性时，可通过弹性预测，实现预热资源。相比于调低阈值进行资源预热，通过 AHPA 可以最大程度的提升资源利用率。

此外由于 AHPA 支持自定义指标配置，Knative 与 AHPA 结合可以做到基于消息队列以及响应延迟 rt 的自动弹性。

基于 rps 使用 AHPA 配置示例如下：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev
        autoscaling.knative.dev/target: "10"
        autoscaling.knative.dev/metric: "rps"
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "30"
        autoscaling.alibabacloud.com/scaleStrategy: "observer"
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

参数说明：

• ta-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

  参数	说明
  autoscaling.knative.dev/class: ahpa.autoscaling.knative.dev	指定弹性插件AHPA。
  autoscaling.knative.dev/metric: "rps"	设置AHPA指标。目前支持concurrency、rps以及响应时间rt。
  autoscaling.knative.dev/target: "10"	设置AHPA指标的阈值，本示例rps阈值为10，表示单个Pod每秒最大处理请求数10。
  autoscaling.knative.dev/minScale: "1"	设置弹性策略实例数的最小值为1。
  autoscaling.knative.dev/maxScale: "30"	设置弹性策略实例数的最大值为30。
  http://autoscaling.alibabacloud.com/scaleStrategy: "observer"	设置弹性伸缩模式，默认值是observer。observer：表示只观察，但不做真正的伸缩动作。您可以通过这种方式观察AHPA的工作是否符合预期。由于预测需要历史7天的数据，因此创建服务默认是observer模式。auto：表示由AHPA负责扩容和缩容，把AHPA指标和阈值输入到AHPA，AHPA最终决定是否生效。

• e data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

小结

本文从 Knative 典型弹性实现 KPA 出发进行介绍，包括如何实现基于请求的自动弹性、缩容到 0、应对突发流量以及我们在 Knative 弹性功能上的扩展增强，包括保留资源池，精准弹性以及弹性预测能力。

作者：元毅

点击立即免费试用云产品 开启云上实践之旅！

原文链接

本文为阿里云原创内容，未经允许不得转载。