Knative Serving 默认情况下，提供了开箱即用的快速、基于请求的自动扩缩容功能 - Knative Pod Autoscaler（KPA）。下面带你体验如何在 Knative 中玩转 Autoscaler。

Autoscaler 机制

Knative Serving 为每个 POD 注入 QUEUE 代理容器 (queue-proxy)，该容器负责向 Autoscaler 报告用户容器并发指标。Autoscaler 接收到这些指标之后，会根据并发请求数及相应的算法，调整 Deployment 的 POD 数量，从而实现自动扩缩容。

算法

Autoscaler 基于每个 POD 的平均请求数（并发数）进行扩所容处理。默认并发数为 100。
POD 数=并发请求总数/容器并发数

如果服务中并发数设置了 10，这时候如果加载了 50 个并发请求的服务，Autoscaler 就会创建了 5 个 POD （50 个并发请求/10=POD）。

Autoscaler 实现了两种操作模式的缩放算法：Stable（稳定模式）和 Panic（恐慌模式）。

稳定模式

在稳定模式下，Autoscaler 调整 Deployment 的大小，以实现每个 POD 所需的平均并发数。 POD 的并发数是根据 60 秒窗口内接收所有数据请求的平均数来计算得出。

恐慌模式

Autoscaler 计算 60 秒窗口内的平均并发数，系统需要 1 分钟稳定在所需的并发级别。但是，Autoscaler 也会计算 6 秒的恐慌窗口，如果该窗口达到目标并发的 2 倍，则会进入恐慌模式。在恐慌模式下，Autoscaler 在更短、更敏感的紧急窗口上工作。一旦紧急情况持续 60 秒后，Autoscaler 将返回初始的 60 秒稳定窗口。

|Panic Target--->  +--| 20|  || <------Panic Window|  |Stable Target--->  +-------------------------|--| 10   CONCURRENCY|                         |  ||                      <-----------Stable Window|                         |  |
--------------------------+-------------------------+--+ 0
120                       60                           0TIME

配置 KPA

通过上面的介绍，我们对 Knative Pod Autoscaler 工作机制有了初步的了解，那么接下来介绍如何配置 KPA。在 Knative 中配置 KPA 信息，需要修改 k8s 中的 ConfigMap：config-autoscaler，该 ConfigMap 在 knative-serving 命名空间下。查看 config-autoscaler 使用如下命令：

kubectl -n knative-serving get cm config-autoscaler

默认的 ConfigMap 如下：

apiVersion: v1
kind: ConfigMap
metadata:name: config-autoscalernamespace: knative-serving
data:container-concurrency-target-default: 100container-concurrency-target-percentage: 1.0enable-scale-to-zero: trueenable-vertical-pod-autoscaling: falsemax-scale-up-rate: 10panic-window: 6sscale-to-zero-grace-period: 30sstable-window: 60stick-interval: 2s

为 KPA 配置缩容至 0

为了正确配置使 Revision 缩容为 0，需要修改 ConfigMap 中的如下参数。

scale-to-zero-grace-period

scale-to-zero-grace-period 表示在缩为 0 之前，inactive revison 保留的运行时间（最小是3 0s）。

scale-to-zero-grace-period: 30s

stable-window

当在 stable mode 模式运行中，autoscaler 在稳定窗口期下平均并发数下的操作。

stable-window: 60s

stable-window 同样可以配置在 Revision 注释中。

autoscaling.knative.dev/window: 60s

enable-scale-to-zero

保证 enable-scale-to-zero 参数设置为 true

Termination period

Termination period（终止时间）是 POD 在最后一个请求完成后关闭的时间。POD 的终止周期等于稳定窗口值和缩放至零宽限期参数的总和。在本例中，Termination period 为 90 秒。

配置并发数

可以使用以下方法配置 Autoscaler 的并发数：

target

target 定义在给定时间（软限制）需要多少并发请求，是 Knative 中 Autoscaler 的推荐配置。

在 ConfigMap 中默认配置的并发 target 为 100。

`container-concurrency-target-default: 100`

这个值可以通过 Revision 中的 autoscaling.knative.dev/target 注释进行修改：

autoscaling.knative.dev/target: 50

containerConcurrency

注意：只有在明确需要限制在给定时间有多少请求到达应用程序时，才应该使用 containerConcurrency (容器并发)。只有当应用程序需要强制的并发约束时，才建议使用 containerConcurrency。

containerConcurrency 限制在给定时间允许并发请求的数量（硬限制），并在 Revision 模板中配置。

containerConcurrency: 0 | 1 | 2-N

1: 将确保一次只有一个请求由 Revision 给定的容器实例处理；
2-N: 请求的并发值限制为2或更多；
0: 表示不作限制，有系统自身决定。

配置扩缩容边界（minScale 和 maxScale）

通过 minScale 和 maxScale 可以配置应用程序提供服务的最小和最大 Pod 数量。通过这两个参数配置可以控制服务冷启动或者控制计算成本。

minScale 和 maxScale 可以在 Revision 模板中按照以下方式进行配置：

spec:template:metadata:autoscaling.knative.dev/minScale: "2"autoscaling.knative.dev/maxScale: "10"

通过在 Revision 模板中修改这些参数，将会影响到 PodAutoscaler 对象，这也表明在无需修改 Knative Serving 系统配置的情况下，PodAutoscaler 对象是可被修改的。

edit podautoscaler <revision-name>

注意：这些注释适用于 Revision 的整个生命周期。即使 Revision 没有被任何 route 引用，minscale 指定的最小 POD 计数仍将提供。请记住，不可路由的 Revision 可能被垃圾收集掉。

默认情况

如果未设置 minscale 注释，pods 将缩放为零（如果根据上面提到的 configmap，enable-scale-to-zero 为 false，则缩放为 1）。

如果未设置 maxscale 注释，则创建的 Pod 数量将没有上限。

基于 KPA 配置的示例

Knative 0.7 版本部署安装可以参考：阿里云部署 Knative

我们使用官方提供的 autoscale-go 示例来进行演示，示例 service.yaml 如下：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:name: autoscale-gonamespace: default
spec:template:metadata:labels:app: autoscale-goannotations:autoscaling.knative.dev/target: "10"spec:containers:- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

获取访问网关：

$ kubectl get svc istio-ingressgateway --namespace istio-system --output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"
121.199.194.150

Knative 0.7 版本中获取域名信息：

$ kubectl get route autoscale-go --output jsonpath="{.status.url}"| awk -F/ '{print $3}'
autoscale-go.default.example.com

场景1：并发请求示例

如上配置，当前最大并发请求数 10。我们执行 30s 内保持 50 个并发请求，看一下执行情况：

hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://121.199.194.150?sleep=100&prime=10000&bloat=5"

结果正如我们所预期的：扩容出来了 5 个 POD。

场景2：扩缩容边界示例

修改一下 servcie.yaml 配置如下：

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:name: autoscale-gonamespace: default
spec:template:metadata:labels:app: autoscale-goannotations:autoscaling.knative.dev/target: "10"autoscaling.knative.dev/minScale: "1"autoscaling.knative.dev/maxScale: "3"     spec:containers:- image: registry.cn-hangzhou.aliyuncs.com/knative-sample/autoscale-go:0.1

当前最大并发请求数 10，minScale 最小保留实例数为 1，maxScale 最大扩容实例数为 3。

我们依然执行 30s 内保持 50 个并发请求，看一下执行情况：

hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://121.199.194.150?sleep=100&prime=10000&bloat=5"

结果如我们所预期：最多扩容出来了 3 个POD，并且即使在无访问请求流量的情况下，保持了 1 个运行的 POD。

结论

看了上面的介绍，是不是感觉在 Knative 中配置应用扩缩容是如此简单？其实 Knative 中除了支持 KPA 之外，也支持K8s HPA。你可以通过如下配置基于 CPU 的 Horizontal POD Autoscaler（HPA）。

通过在修订模板中添加或修改 autoscaling.knative.dev/class 和 autoscaling.knative.dev/metric 值作为注释，可以将Knative 配置为使用基于 CPU 的自动缩放，而不是默认的基于请求的度量。配置如下：

spec:template:metadata:autoscaling.knative.dev/metric: concurrencyautoscaling.knative.dev/class: hpa.autoscaling.knative.dev

你可以自由的将 Knative Autoscaling 配置为使用默认的 KPA 或 Horizontal POD Autoscaler（HPA）。

欢迎加入 Knative 交流群

Knative 基本功能深入剖析：Knative Serving 自动扩缩容 Autoscaler相关推荐

Knative 驾驭篇：带你 '纵横驰骋' Knative 自动扩缩容实现
Knative 中提供了自动扩缩容灵活的实现机制,本文从三横两纵的维度带你深入了解 KPA 自动扩缩容的实现机制.让你轻松驾驭 Knative 自动扩缩容. 注:本文基于最新 Knative v0 ...
Serverless Knative Serving弹性扩缩容实践整理
文章目录 (一)基础 (1)认识 (2)Knative Serving对象模型 (3)knative-serving (4)Knative的扩缩容流程原理 (二)弹性扩缩容实践 (1)自动扩缩容类型选 ...
K8S集群Pod资源自动扩缩容方案
K8S集群Pod资源自动扩缩容方案 1.为什么要是有自动扩缩容在K8S集群中部署的应用程序都是以Pod的形式部署的,我们在部署Pod资源时都会指定Pod资源的副本数,但是这个数量是写死的,平时可能启 ...
Kubernetes：HPA 详解-基于 CPU、内存和自定义指标自动扩缩容
目录 HPA 基本原理 Metrics Server 聚合 API 安装Metrics Server HPA 基于 CPU自动扩缩容查看 HPA 资源的对象了解工作过程: HPA 基于内存自动扩缩 ...
通过Dapr实现一个简单的基于.net的微服务电商系统(十一)——一步一步教你如何撸Dapr之自动扩/缩容...
上一篇我们讲到了dapr提供的bindings,通过绑定可以让我们的程序轻装上阵,在极端情况下几乎不需要集成任何sdk,仅需要通过httpclient+text.json即可完成对外部组件的调用,这样 ...
k8s自定义指标HPA实践（微服务基于自定义指标自动扩缩容的实践）附demo
先上demo代码仓库 https://github.com/wentjiang/prometheus-HPA-test 自动扩缩容的使用场景在开发微服务时,我们会有一些请求量突增的场景,举个例子,快 ...
k8s自动扩缩容、健康检查、Qos、资源管理、亲和度、污点与宽容
环境为centos7.9 安装k8s 1.23.1 一.自动扩缩容 1.安装Metrics Server wget https://github.com/kubernetes-sigs/metrics ...
8.HPA自动扩缩容
1 什么是HPA? HPA(Horizontal Pod Autoscaler,水平Pod自动伸缩器)可根据观察到的CPU.内存使用率或自定义度量标准来自动扩展或缩容Pod的数量.HPA不适用于无法缩 ...
22,Horizontal Pod Autoscaler(HPA)，自动扩缩容
在前面的课程中,我们已经可以实现通过手工执行kubectl scale命令实现Pod扩容或缩容,但是这显然不符合Kubernetes的定位目标–自动化.智能化. Kubernetes期望可以实现通过监 ...

Knative 基本功能深入剖析：Knative Serving 自动扩缩容 Autoscaler