当您的应用在进行扩容、部署新版本或预期流量突增时,可以使用ASM慢启动预热功能,在自定义的时间窗口内逐步增加请求流量,从而平稳过渡,降低因瞬间压力过高导致的服务中断、请求超时及潜在的数据丢失风险,确保应用在伸缩和更新过程中的性能稳定性和高可用性。
前提条件
已创建ASM企业版或者旗舰版实例,且版本为1.14.3及以上。具体操作,请参见创建ASM实例。
已添加集群到ASM实例。具体操作,请参见添加集群到ASM实例。
通过kubectl连接ACK集群。具体操作,请参见获取集群KubeConfig并通过kubectl工具连接集群。
已创建ASM网关。具体操作,请参见创建入口网关服务。
已部署示例应用Bookinfo。本文以Reviews服务为例,具体操作,请参见在ASM实例关联的集群中部署应用。
背景信息
在未启用慢启动预热功能时,每当新目标Pod加入时,请求方都会向该Pod发送一定比例的流量,不支持新Pod的渐进式流量增加。这对于需要一些预热时间来提供全部负载的服务可能是不可取的,并且可能会导致请求超时、数据丢失和用户体验恶化。例如在基于JVM的Web应用程序中,这些应用程序使用水平Pod自动缩放。当服务刚启动时,它会被大量请求淹没,这会导致应用程序预热时持续超时。因此,每次扩展服务时,都会丢失数据或者会导致这部分请求的响应时间增加。预热的基本思想就是让刚启动的机器逐步接入流量。
慢启动预热功能介绍
慢启动模式又称渐进式流量增加,用户可以为服务配置一个时间段,每当一个服务实例启动时,请求方会向该实例发送一部分请求负载,并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达,就会退出慢启动模式。
在慢启动模式下,添加新的目标服务Pod时,避免新增Pod被大量请求击垮,这些新目标服务可以根据指定的加速期在接受其均衡策略的请求之前进行预热。
慢启动对于依赖缓存并且需要预热期才能以最佳性能响应请求的应用程序非常有用。在ASM下,您只需在服务对应的DestinationRule下的配置trafficPolicy/loadBalancer
即可,需要注意的是:
loadBalancer:表示负载均衡器信息。类型限定于ROUND_ROBIN和LEAST_REQUEST负载均衡器。
warmupDurationSecs:表示Service的预热持续时间。如果设置,则新创建的服务端点在此窗口期间从其创建时间开始保持预热模式,并且Istio逐渐增加该端点的流量,而不是发送成比例的流量。
慢启动要求应用当前副本数不小于2。例如:原本有2个副本,启动第三个时,慢启动会生效。如果当前只有1个副本,新启动1个副本,慢启动不会生效。
DestinationRule的YAML示例如下:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mocka
spec:
host: mocka
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
warmupDurationSecs: 100s
步骤一:配置路由规则并访问入口网关
为方便演示,本文先将Reviews的v3版本的Deployment副本数调整为0,即在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数缩容为0。
定义访问入口。
使用以下内容,创建bookinfo-gateway.yaml文件。
执行以下命令,部署bookinfo-gateway。
kubectl apply -f bookinfo-gateway.yaml
创建Reviews服务。
使用以下内容,创建reviews.yaml文件。
执行以下命令,部署Reviews。
kubectl apply -f reviews.yaml
开启网格拓扑, 持续访问入口网关地址。
本文以通过hey命令发送压测请求10s为例。关于hey命令的下载和安装,请参见hey;关于开启和查看网格拓扑的具体操作,请参见查看应用的网格拓扑。
hey -z 10s -q 100 -c 4 http://${网关地址}/reviews/0
调用拓扑示例图如下:
步骤二:通过可观测数据查看Pod启动
登录ASM控制台。
在左侧导航栏,选择 。
在网格管理页面,找到待配置的实例,单击实例的名称或在操作列中单击管理。
在左侧导航栏单击 。
ASM实例版本为1.17.2.35以下:在监控指标页面,单击监控仪表页签,然后单击网格服务级别监控页签,选择对应的Reviews服务。
ASM实例版本为1.17.2.35及以上:在监控指标页面,单击网格工作负载级别监控页签,选择对应的reviews-v3工作负载,选择Reporter为source。
发送压测请求并观察监控数据。
在未开启预热功能的情况下,在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数从0扩容为1。
执行以下命令,发送压测请求入口网关。
本文以发送压测请求120s为例。
hey -z 120s -q 100 -c 4 http://${网关地址}/reviews/0
观察Prometheus监控的仪表盘数据。
大约需要45s左右,reviews-v3 Pod将接收均衡的请求(具体时间会跟实际压测环境有关)。
在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数缩容为0。
步骤三:启用预热功能
使用以下内容,更新reviews.yaml文件。
增加
warmupDurationSecs
字段,配置为120s
,即定义预热持续时间为120s。apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: ROUND_ROBIN warmupDurationSecs: 120s
执行以下命令,更新Reviews。
kubectl apply -f reviews.yaml
步骤四:查看预热效果
开启预热功能后,在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数从0扩容为1。
执行以下命令,发送压测请求入口网关。
本文以发送压测请求150s为例。
hey -z 150s -q 100 -c 4 http://${网关地址}/reviews/0
在网格服务级别监控页签中,观察Prometheus监控的仪表盘数据。
大概需要120s左右,reviews-v3 Pod将接收均衡的请求(具体时间会跟实际压测环境有关)。由于Metrics的采集时间间隔限制,这条曲线并不平滑。实际上,到达reviews-v3 pod的流量是平滑增长的,如果您开启了Sidecar日志采集,可以在SLS中搜索这个Sidecar对应的日志,可以看到近5分钟的日志量。在启用预热功能的情况下,每当一个服务实例启动时,请求方会向该实例发送一部分请求负载,并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达,就会退出慢启动模式。
启用预热功能之后,需要2分30秒左右,流量将均衡地分布到v1、v2、v3版本。
相关文档
您可以配置本地限流或全局限流,将流量维持在可控的阈值内,确保服务持续可用并维持性能稳定。具体操作,请参见在流量管理中心配置本地限流和使用ASMGlobalRateLimiter对应用服务入口流量配置全局限流。
您可以使用ASMAdaptiveConcurrency实现自适应并发控制,根据采样的请求数据动态调整允许的并发的数量,当并发数量超过服务可承受范围时拒绝请求,达到保护服务的目的。具体操作,请参见使用ASMAdaptiveConcurrency实现自适应并发控制。
您可以配置连接池实现熔断功能,在系统出现故障或超负荷的情况下,保护系统免受进一步的损害。具体操作,请参见配置连接池实现熔断功能。