使用ASM管理Knative服务(6):基于流量请求数实现服务自动扩缩容

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: Knative on ASM中提供了开箱即用、基于流量请求的自动扩缩容KPA(Knative Pod Autoscaler)功能。本文介绍如何基于流量请求数实现服务自动扩缩容。

Knative on ASM中提供了开箱即用、基于流量请求的自动扩缩容KPA(Knative Pod Autoscaler)功能。本文介绍如何基于流量请求数实现服务自动扩缩容。

本系列文章包括以下部分:

使用ASM管理Knative服务(1):Knative on ASM概述

使用ASM管理Knative服务(2):使用Knative on ASM部署Serverless应用

使用ASM管理Knative服务(3):在Knative on ASM中使用自定义域名

使用ASM管理Knative服务(4):使用ASM网关实现HTTPS访问Knative服务

使用ASM管理Knative服务(5):在Knative on ASM中基于流量灰度发布服务

使用ASM管理Knative服务(6):基于流量请求数实现服务自动扩缩容

前提条件

背景介绍

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

image.png

并发数和QPS

  • 并发数是同一时刻Pod的接收的请求数。
  • QPS指的是Pod每秒响应的请求数,也就是最大吞吐能力。

并发数的增加并不一定会导致QPS增加。应用在访问压力较大的情况下,如果并发数增加,系统的QPS反而会下降。因为系统超负荷工作,CPU、内存等其他消耗导致系统性能下降,从而导致响应延迟。

具体算法参见: https://help.aliyun.com/document_detail/186137.html

如果需要在Knative中使用HPA, 参见:https://help.aliyun.com/document_detail/188160.html

KPA配置介绍

配置KPA

配置KPA,需要配置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: "0.7"
 enable-scale-to-zero: "true"
 max-scale-up-rate: "1000"
 max-scale-down-rate: "2"
 panic-window-percentage: "10"
 panic-threshold-percentage: "200"
 scale-to-zero-grace-period: "30s"
 scale-to-zero-pod-retention-period: "0s"
 stable-window: "60s"
 target-burst-capacity: "200"
 requests-per-second-target-default: "200"

为KPA配置缩容至0

字段 描述 设置值
scale-to-zero-grace-period 表示在缩为0之前,inactive revison保留的运行时间(最小是30s) 30s
stable-window 当在Stable模式运行中,Autoscaler在稳定窗口期下平均并发数下的操作。此外, stable-window也可以在Revision注释中配置。autoscaling.knative.dev/window: 60s 60s
enable-scale-to-zero 设置enable-scale-to-zero参数为true true

配置Autoscaler的并发数

字段 描述 设置值
container-concurrency-target-default 定义在给定时间(软限制)需要多少并发请求,是Knative中Autoscaler的推荐配置。在ConfigMap中默认配置的并发target为100。此外, 这个值也可以通过Revision中的autoscaling.knative.dev/target注释进行修改。autoscaling.knative.dev/target: 50 100
containerConcurrency 当在Stable模式运行中,Autoscaler在稳定窗口期下平均并发数下的操作。此外, stable-window也可以在Revision注释中配置。autoscaling.knative.dev/window: 60s 60s
container-concurrency-target-percentage 这个参数为并发百分比或称为并发因子,并且会直接参与扩缩容并发数计算。例如,如果并发数target或者containerConcurrency设置值为100,并发因子container-concurrency-target-percentage为0.7。那么实际担当并发数达到70(1000.7)时就会触发扩容操作。因此,实际扩缩容并发数=target(或者containerConcurrencycontainer-concurrency-target-percentage 0.7

配置扩缩容边界

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

说明:

  • 如果未设置minScale注释,Pods将缩放为零。如果设置config-autoscalerenable-scale-to-zerofalse,则缩放为1。
  • 如果未设置maxScale注释,则创建的Pod数量将没有上限。

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

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

场景一:设置并发请求数实现自动扩缩容

本场景示例将通过设置并发请求数,通过KPA实现自动扩缩容。
请按照以下步骤在集群中部署autoscale-go应用。关于快速部署Serverless应用的操作细节,可以参考 使用Knative on ASM快速部署Serverless应用

1) 创建autoscale-go.yaml。设置并发目标数为10。

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

2) 使用kubectl连接到集群,在命令行执行以下命令部署autoscale-go

kubectl apply -f autoscale-go.yaml 

3) 登录ASM服务网格控制台查看ASM网关。
4)使用Hey压测工具,执行30s内保持50个并发请求(请将xxx.xx.xx.xxx替换为您的网关ip)。

说明 Hey压测工具的详细介绍,请参见 Hey
hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xx.xx.xxx?sleep=100&prime=10000&bloat=5"

预期输出:
image.png

从结果可以看出,整个过程中扩容了7个Pod。这是由于当容器并发量大于目标并发量的一定百分比后(默认为70%),knative会提前创建出更多的Pod备用以免并发量进一步增的情况下,目标值被突破。

场景二:设置扩缩容边界实现自动扩缩容

扩缩容边界指应用程序提供服务的最小和最大Pod数量。通过设置应用程序提供服务的最小和最大Pod数量实现自动扩缩容。
请按照以下步骤在集群中部署autoscale-go应用。关于快速部署Serverless应用的操作细节,可以参考使用Knative on ASM快速部署Serverless应用

1) 创建autoscale-go.yaml。设置最大并发请求数为10,minScale最小保留实例数为1,maxScale最大扩容实例数为3。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: autoscale-go
  namespace: default
spec:
  template:
    metadata:
      labels:
        app: autoscale-go
      annotations:
        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

2) 使用kubectl连接到集群,在命令行执行以下命令部署autoscale-go

kubectl apply -f autoscale-go.yaml 

3) 登录ASM服务网格控制台查看ASM网关。
4) 使用Hey压测工具,执行30s内保持50个并发请求(请将xxx.xx.xx.xxx替换为您的网关ip)。

说明 Hey压测工具的详细介绍,请参见 Hey
hey -z 30s -c 50   -host "autoscale-go.default.example.com"   "http://xxx.xx.xx.xxx?sleep=100&prime=10000&bloat=5"

预期输出:
image.png

结果和我们配置的一致,最多扩容出来了3个Pod,并且即使在无访问请求流量的情况下,保持了1个运行的Pod。

相关文章
|
18天前
|
运维 Kubernetes 安全
利用服务网格实现全链路mTLS(一):在入口网关上提供mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,用于简化服务治理,包括流量管理和拆分、安全认证及网格可观测性,有效减轻开发运维负担。ASM支持通过mTLS提供服务,要求客户端提供证书以增强安全性。本文介绍如何在ASM入口网关上配置mTLS服务并通过授权策略实现特定用户的访问限制。首先需部署ASM实例和ACK集群,并开启sidecar自动注入。接着,在集群中部署入口网关和httpbin应用,并生成mTLS通信所需的根证书、服务器证书及客户端证书。最后,配置网关上的mTLS监听并设置授权策略,以限制特定客户端对特定路径的访问。
72 2
|
18天前
|
Prometheus Kubernetes 监控
打造无缝灾备新境界:运用服务网格ASM,将集群外服务无缝融入集群内服务,铸就高可用性坚盾!
【8月更文挑战第2天】随着微服务架构的应用,服务的高可用性变得至关重要。服务网格如阿里巴巴的ASM提供流量管理、服务发现等功能,支撑高可靠服务系统。本文介绍如何利用ASM实现集群外服务作为集群内服务的灾备方案,确保服务连续性。先决条件包括已部署ASM的Kubernetes集群环境及内外部的关键服务副本。通过定义服务条目、配置虚拟服务和目的地规则,可实现自动或手动故障转移。借助ASM的流量管理能力,确保服务高可用性和业务连续性。
32 10
|
18天前
|
Perl
如何利用服务网格ASM使用集群外服务做集群内服务的灾备
本文档指导您如何配置阿里云服务网格(ASM)以实现在多集群环境下,服务间的优先访问及故障转移策略。
75 2
|
18天前
|
Kubernetes 安全 数据安全/隐私保护
利用服务网格实现全链路mTLS(二):通过出口网关访问外部mTLS服务
阿里云服务网格(Service Mesh,简称ASM)提供了一个全托管式的服务网格平台,兼容Istio开源服务网格,简化服务治理,包括流量管理、服务间通信安全及网格可观测性。ASM出口网关统一管理网格内的出口流量,实现全链路加密通信与精细访问控制。本文介绍如何配置ASM出口网关以管理出口流量并发起mTLS通信,涉及配置ServiceEntry、创建出口网关、设置虚拟服务及目标规则等步骤,最终实现安全可控的mTLS服务访问。
78 3
|
2月前
|
Cloud Native 容器 Kubernetes
基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道
本文简要讨论了使用流量泳道来实现全链路流量灰度管理的场景与方案,并回顾了阿里云服务网格 ASM 提供的严格与宽松两种模式的流量泳道、以及这两种模式各自的优势与挑战。接下来介绍了一种基于 OpenTelemetry 社区提出的 baggage 透传能力实现的无侵入式的宽松模式泳道,这种类型的流量泳道同时具有对业务代码侵入性低、同时保持宽松模式的灵活特性的特点。同时,我们还介绍了新的基于权重的流量引流策略,这种策略可以基于统一的流量匹配规则,将匹配到的流量以设定好的比例分发到不同的流量泳道。
73490 16
基于阿里云服务网格流量泳道的全链路流量管理(三):无侵入式的宽松模式泳道
|
1月前
|
人工智能 自然语言处理 安全
使用阿里云服务网格高效管理LLM流量:(一)流量路由
ASM支持通过LLMProvider和LLMRoute资源管理大型语言模型流量。LLMProvider负责注册LLM服务,LLMRoute负责设定流量规则,应用可灵活切换模型,满足不同场景需求。
|
3月前
|
存储 机器学习/深度学习 负载均衡
模型服务网格:云原生下的模型服务管理
模型服务网格:云原生下的模型服务管理
78435 5
模型服务网格:云原生下的模型服务管理
|
10月前
|
监控 安全 大数据
阿里服务的ASM、MSE和ARMS都有其各自的应用场景
阿里服务的ASM、MSE和ARMS都有其各自的应用场景
283 39
|
9月前
|
Kubernetes API 容器
基于阿里云服务网格流量泳道的全链路流量管理(二):宽松模式流量泳道
基于阿里云服务网格流量泳道的全链路流量管理(二):宽松模式流量泳道
10936 11
|
3月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。