Serverless Knative Serving弹性扩缩容实践整理

文章目录

（一）基础
- （1）认识
- （2）Knative Serving对象模型
- （3）knative-serving
- （4）Knative的扩缩容流程原理
（二）弹性扩缩容实践
- （1）自动扩缩容类型选择
- - 1. 介绍
  - 2.配置示例
- （2）缩容至0和冷启动问题
- （3）Knative Service的弹性伸缩配置
- （4）Knative Service灰度发布实践
（三）参考命令
（四）参考

（一）基础

（1）认识

Knative的服务管理组件Serving是管理应用服务的理想选择，它通过自动缩容为零和基于HTTP负载自动扩展的方式简化了部署流程。Knative平台可管理应用服务的部署、版本、网络、扩缩容。

（2）Knative Serving对象模型

【1】服务（Service）：service.serving.knative.dev资源自动管理用户工作负载的整个生命周期。它控制路由和配置对象的创建，在服务更新时确保应用有对应的服务路由、配置和新的修订版。服务可以被定义为总是把流量路由到最新的修订版或特定修订版。
【2】路由（Route）：route.serving.knative.dev资源用于映射一个网络端点到一个或更多修订版。你可以用多种方式来管理流量，包括分流和命名路由。
【3】配置（configuration）：configuration.serving.knative.dev资源维护了部署应用的最终状态。它遵循云原生应用12要素原则，提供了代码和配置分离的机制。每次修改配置会创建一个新的修订版。
【4】修订版（Revision）：revision.serving.knative.dev资源是在每次变更工作负载时生成的代码和配置的时间点快照。修订版是不可变对象。系统会保留有用的修订版本，删除不再使用的修订版。修订版对应的Pod实例数量会根据流量的大小自动进行伸缩。

（3）knative-serving

Knative Serving组件在启动时会自动创建如上所示的一些pod工作负载，这些pod构成了Serving的整体管理能力。(备注：并非所有场景默认都是如上组件)
【1】activator（Service）：负责为不活跃状态的修订版接收并缓存请求，同时报告指标数据给Autoscaler。在Autoscaler扩展修订版之后，它还负责将请求重试到修订版
【2】autoscaler（Service）：接收请求指标数据并调整需要的Pod 数量以处理流量负载。
【3】autoscaler-hpa ：接收请求指标数据并调整需要的Pod 数量以处理流量负载。针对于 Horizontal Pod Autoscaler (HPA) 扩缩容类型实现。
【4】Controller（Service）：协调所有公共Knative对象，自动扩展CRD。当用户请求一个Knative Service给Kubernetes API时，Controller将创建对应配置和路由，并将配置转换为revision，同时将revision转化为Deployment和KPA。
【5】default-domain：默认域名设置。默认情况下，路由的完全限定域名是{route}.{namespace}.{default-domain}. Knative Serving 路由example.com用作默认域。
【6】domain-mapping：自定义域名设置
【7】domainmapping-webhook：域名映射拦截处理模块
【8】net-kourier-controller：Knative Kourier 网关控制器；
【9】webhook ：Webhook（Service）：拦截所有Kubernetes API调用以及所有CRD的插入和更新操作，用来设置默认值，拒绝不一致和无效的对象，验证和修改Kubernetes API调用。

（4）Knative的扩缩容流程原理

【1】默认情况下，创建后的Pod副本在没有请求后会变成0，缩容到0。当新的请求过来时，首先通过入口网关转发给Activator组件，并报告数据给Autoscaler组件。
【2】接着Autoscaler会创建修订版的Deployment对象，构建相应的Pod副本。
【3】Activator会将缓存的客户端请求转发给对应的Pod副本。Gateway然后会将新的请求直接转发给相应的Pod副本，不再转发给Activator。
【4】Autoscaler创建的pod中默认都有俩个容器，一个是User Container即对应的业务服务，一个是Queue Proxy是系统容器，以Sidecar方式存在，该容器负责向Autoscaler报告用户容器流量指标。Autoscaler接收到这些指标之后，会根据流量指标及相应的算法调整Deployment的Pod副本数量，从而实现自动扩缩容，如果一段周期内没有请求，Autoscaler会将Pod副本数设置为零，回收Pod所占资源。
【5】Autoscaler默认基于Pod接收到的并发请求数扩缩容资源。计算公式是：Pod数=并发请求总数/Pod并发请求数的目标值。

（二）弹性扩缩容实践

（1）自动扩缩容类型选择

1. 介绍

Knative Serving 支持 Knative Pod Autoscaler (KPA) 和 Kubernetes 的 Horizontal Pod Autoscaler (HPA) 的实现。
KPA：Knative Serving 核心的一部分，安装 Knative Serving 后默认启用。支持缩放到零功能。不支持基于 CPU 的自动缩放。
HPA：不是 Knative Serving 核心的一部分，需要单独安装。不支持缩放到零功能。支持基于 CPU 的自动缩放。
如果想要支持KPA，需要单独安装，安装方式如下：

kubectl apply -f serving-hpa.yaml

yaml配置文件下载地址：https://github.com/knative/serving/releases，注意保持版本统一

修改自动扩缩容类型选择可以有俩种设置方式，一个是Global (ConfigMap)全局设置，一个是Per Revision特定的修订版本设置

2.配置示例

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloworld-nodejs
spec:template:metadata:labels:app: helloworld-nodejsannotations:autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"autoscaling.knative.dev/metric: "cpu"autoscaling.knative.dev/target: "75"autoscaling.knative.dev/minScale: "1"autoscaling.knative.dev/maxScale: "10"spec:containers:- image: registry.cn-hangzhou.aliyuncs.com/knative-samples/helloworld-go:160e4dc8resources:requests:cpu: '200m'

1：通过autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"指定HPA弹性插件。
2:通过autoscaling.knative.dev/metric设置HPA CPU指标。
3:通过autoscaling.knative.dev/target设置HPA CPU指标的阈值。
4:通过autoscaling.knative.dev/minScale: "1"设置弹性策略实例数的最小值。
5:通过autoscaling.knative.dev/maxScale: "10"设置弹性策略实例数的最大值。

上面的配置信息是针对Per Revision构建方式。构建命令通过kubectl apply 即可

上面的autoscaling.knative.dev/metric属性设置了监控指标类型。指标可以是"concurrency", “rps” or “cpu” 。即并发数、每秒请求数、CPU使用率。
默认的设置是Default: “concurrency”

（2）缩容至0和冷启动问题

缩容至0可以被启用在设置KnativePodAutoscaler (KPA)类型下，且仅可以设置为全局配置。缩放到零值控制 Knative 是否允许副本缩小到零（如果设置为 true），或者如果设置为 false，则停止在 1 个副本。
属性配置键为：enable-scale-to-zero。默认是true，即支持缩容至0个pod，设置为false,会保留一个副本

注意：这里着重说明下这个属性，这个属性是config-autoscaler的ConfigMap，我们可以通过下面命令查看其属性信息

kubectl -n knative-serving  describe cm  config-autoscaler

默认是true代表可以缩容至0。虽然缩容至0可以有效的节省服务器资源的消耗，但是也带来了一个很关键的问题，即Serverless中的冷启动问题，就拿自己参与项目为例，一个应用镜像打包后超过900M，如果缩容至0，那么在空闲后第一批请求过来了冷启动的时间可能需要至少30s的时间才能启动镜像，而这对于用户使用无疑是不友好的，所以我们对于一些核心，启动耗时的应用需要进行预留实例，保留至少一个实例，这样在新的请求过来可以立马响应，对用户使用没有影响。

Tips：除了enable-scale-to-zero方式之外，还可以通过设置annotations的autoscaling.knative.dev/minScale来限制当前服务至少有一个负载存活

如果需要设置的话，可以将config-autoscaler组件的configMap的enable-scale-to-zero设置为false

kubectl -n knative-serving  edit cm  config-autoscaler

enable-scale-to-zero属性值控制Knative修订版缩容到零或保留1个副本。scale-to-zero-grace-period属性值控制的是缩容到零的宽限周期。缩容到零的宽限周期是指系统在删除最后一个副本之前等待的时间上限。默认值：30s。
参考配置如下

apiVersion: v1
kind: ConfigMap
metadata:name: config-autoscalernamespace: knative-serving
data:scale-to-zero-grace-period: "40s"

scale-to-zero-pod-retention-period属性控制的是缩容到零时最后一个Pod的保留期。scale-to-zero-pod-retention-period定义了当Autoscaler决定要缩容到零时，最后一个Pod保留的最小时长。该设置主要针对那些启动代价高、流量突发性高的场景。默认值：0s。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloworld-gonamespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/scaleToZeroPodRetentionPeriod: "1m5s"spec:containers:- image: gcr.io/knative-samples/helloworld-go

（3）Knative Service的弹性伸缩配置

Knative Serving为我们提供了一些扩缩容配置项，包括副本的初始大小，pod副本最小数量，最大数量限制。下面通过简单的实例去分析下这些弹性伸缩配置
【1】准备测试服务配置文件，参考如下

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: helloworld-go  # Service名称namespace: default
spec:template:metadata:annotations:autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev" # Autoscaler的实现方式,可选值有"kpa.autoscaling.knative.dev" 或 "hpa.autoscaling.knative.dev"autoscaling.knative.dev/metric: "concurrency"  # 设置度量指标为concurrency（默认值），还可以根据业务情况选择rps或cpu。autoscaling.knative.dev/target: "10"  # 设置单个Pod最大并发数为10，默认值为100。autoscaling.knative.dev/minScale: "1" # minScale表示最小保留实例数为1autoscaling.knative.dev/maxScale: "100" # maxScale表示最大扩容实例数为3spec:containerConcurrency: 10 # 并发请求数的硬性限制。containers:- image: cnlab/helloworld-go

在上述配置中，revision中配置了修订版的弹性伸缩策略。各个属性代表的意义如下。
·autoscaling.knative.dev/class：表示Autoscaler的实现方式，这个属
性的可选值有kpa.autoscaling.knative.dev或hpa.autoscaling.knative.dev。 KPA支持缩容到零，HPA支持基于CPU的扩展机制。
·autoscaling.knative.dev/metric：度量指标默认为并发数，该属性
还可以根据业务情况选择每秒请求数或CPU使用率。
·autoscaling.knative.dev/target：自动缩放的目标值是Autoscaler维
护应用的每个副本度量指标的目标值。
·autoscaling.knative.dev/minScale：表示每个修订版副本需要保留
的最小数量。在任何时间点，副本不会少于这个数量。通过该设置，
我们可以有效地减少服务的冷启动时间。
·autoscaling.knative.dev/maxScale：表示每个修订版副本所能达到
的最大数量。在任何时间点，副本都不会超过指定的最大值，从而避
免资源被过度使用。

上面的配置仅使用了一部分，具体的可以参考官方文档：
https://knative.dev/v1.0-docs/serving/autoscaling/scale-bounds/

【2】创建应用服务

kubectl apply  -f service.yaml

可以通过rancher看到已经创建了pod，也可以通过下面的命令查看

kubectl  get pod -l serving.knative.dev/service=helloworld-go

【3】因为设置了 autoscaling.knative.dev/minScale: “1” ，其中 minScale表示最小保留实例数为1，通过上图可以观察到存在一个pod

【4】Autoscaler基于每个Pod的平均请求数（并发数）进行自动扩缩容，默认并发数为100。Pod数=并发请求总数/容器并发数。如果服务中并发数设置为10，并且加载了50个并发请求的服务，则Autoscaler就会创建5个Pod。

【5】下面通过hey压测工具进行测试
备注：下面的压测工具使用的是hey,为了方便建议这里直接使用二进制包的方式
二进制包地址：
https://hey-release.s3.us-east-2.amazonaws.com/hey_linux_amd64

查看该pod分配的域名地址

kubectl get ksvc --namespace default

执行压力测试，发起50个并发请求，持续30秒对hellowrold-go服务进行压测。

./hey_linux_amd64   -c  50 -z 30s -host "helloworld-go.default.127.0.0.1.nip.io" "http://ip:30218"

执行压测结束后，查看工作负载情况，执行命令

kubectl  get pod -l serving.knative.dev/service=helloworld-go

正常情况下当发起的并发请求数是50个，服务自动缩放的目标值是10，按照“副本数=并发数/目标值”算法，那么pod数量就是5。但是在某些情况下，由于Knative Serving还有一个控制参数叫目标使用率，一旦并发数达到预设目标的70%（默认值），Autoscaler就会继续扩容。引入目标使用率的主要目的是在扩容时减小由Pod启动时间带来的延迟，使负载到达前就将Pod实例启动起来。

【6】在等待几分钟后，再次查询就会发现pod数有降成1了，仅保留一个实例

（4）Knative Service灰度发布实践

灰度部署是指逐渐将生产环境流量从老版本切换到新版本。通常流量是按比例分配的。例如 90% 的请求流向老版本，10% 的请求流向新版本。然后没有发现问题，就逐步扩大新版本上的流量，减少老版本上的流量。
除了切流量外，对于多租户的平台，例如云计算平台，灰度部署也可以将一些新的版本先部署到一些用户上，如果没有问题，扩大部署，直到全部用户。一般的策略是，从内部用户开始，然后是一般用户，最后是大客户。
这个技术大多数用于缺少足够测试，或者缺少可靠测试，或者对新版本的稳定性缺乏信心的情况下。
把一部分用户切到新版上来，然后看一下有没有问题。如果没有问题就继续扩大升级，直到全部升级完成。
这里准备实例，当前所使用的是一个单体化项目，演示的场景如下：
【1】构建俩个版本的应用，这俩个版本一个作为旧版本，一个作为升级后的版本。通过不断变更的流量比例来实现应用服务灰度发布，当前设置俩个revision各占50%的流量，即切换一半用户访问至新版本。
【2】俩个版本应用的镜像通过docker push推送到私库中：
【3】构建工作负载配置文件如下

apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: tag-headernamespace: serving-test
spec:template:metadata:name: tag-header-revision-1spec:containers:- image:  #镜像1env:- name: TARGETvalue: "First Revision"
---
apiVersion: serving.knative.dev/v1
kind: Service
metadata:name: tag-headernamespace: serving-test
spec:template:metadata:name: tag-header-revision-2spec:containers:- image: #镜像2env:- name: TARGETvalue: "Second Revision"traffic:- tag: v1revisionName: tag-header-revision-1percent: 50                      # 流量切分的百分比值- tag: v2revisionName: tag-header-revision-2percent: 50                      # 流量切分的百分比值

【5】通过浏览器进行测试，由于是在内网自动分配的域名需修改本地的hosts文件

192.168.XXX.XXX tag-header.serving-test.127.0.0.1.nip.io

【6】Knative默认使用的是kourier网关，现在需要看下该网关暴露的端口入口信息，当前我们使用30218端口测试

kubectl --namespace kourier-system get service kourier

【7】测试tag-header.serving-test，观察下面可以看到多次访问时返回数据不同
测试地址：http://tag-header.serving-test.127.0.0.1.nip.io:30218/

通过多次访问该地址可以发现结果不同，对应的流量被划分到不同的应用服务中去了

（三）参考命令

【1】根据描述文件创建应用

kubectl apply -f  service.yaml

【2】查看 Knative 工作负载

# 查询命名空间serving-test下的工作负载
kubectl get ksvc --namespace serving-test

【3】查看应用详细信息

#  查看knative-serving命名空间下configMap名称config-autoscaler的详细信息
kubectl -n knative-serving  describe cm  config-autoscaler# 查询命名空间knative-serving下pod名称为activator-645854dc69-b9ds9的详细信息
kubectl describe pod activator-645854dc69-b9ds9 --namespace knative-serving

【4】编辑配置

#  编辑knative-serving命名空间下configMap名称config-autoscaler的详细信息
kubectl -n knative-serving  edit cm  config-autoscaler

【5】查询pod信息

kubectl  get pod -l serving.knative.dev/service=helloworld-go

【6】查看pod日志

kubectl logs输出pod中一个容器的日志。输出pod中一个容器的日志。如果pod只包含一个容器则可以省略容器名。

 kubectl logs [-f] [-p] POD [-c CONTAINER]# 查看knative-serving命名空间中pod名称autoscaler-78cd799dcc-zwk9l的日志信息
kubectl logs -f autoscaler-78cd799dcc-zwk9l --namespace  knative-serving

（四）参考

【1】基于流量请求数实现服务自动扩缩容
https://knative.club/02serving/zi-dong-kuo-suo-rong-kpa-pei-zhi/ji-yu-liu-liang-qing-qiu-shu-shi-xian-fu-wu-zi-dong-kuo-suo-rong

【2】《Knative实战：基于Kubernetes的无服务器架构实践》Knative的服务管理组件Serving

【3】详解 Knative Serving
https://www.jianshu.com/p/10b5b68e8cb1

【4】knative官方文档弹性伸缩模块
https://knative.dev/v1.0-docs/serving/autoscaling/

【5】阿里云开发者社区knative Serving
https://www.aliyun.com/search?k=Knative%20Serving&page=1&scm=