全部产品
Search
文档中心

服务网格 ASM:使用ASM慢启动预热功能

更新时间:Dec 04, 2024

当您的应用在进行扩容、部署新版本或预期流量突增时,可以使用ASM慢启动预热功能,在自定义的时间窗口内逐步增加请求流量,从而平稳过渡,降低因瞬间压力过高导致的服务中断、请求超时及潜在的数据丢失风险,确保应用在伸缩和更新过程中的性能稳定性和高可用性。

前提条件

背景信息

在未启用慢启动预热功能时,每当新目标Pod加入时,请求方都会向该Pod发送一定比例的流量,不支持新Pod的渐进式流量增加。这对于需要一些预热时间来提供全部负载的服务可能是不可取的,并且可能会导致请求超时、数据丢失和用户体验恶化。例如在基于JVM的Web应用程序中,这些应用程序使用水平Pod自动缩放。当服务刚启动时,它会被大量请求淹没,这会导致应用程序预热时持续超时。因此,每次扩展服务时,都会丢失数据或者会导致这部分请求的响应时间增加。预热的基本思想就是让刚启动的机器逐步接入流量。

慢启动预热功能介绍

慢启动模式又称渐进式流量增加,用户可以为服务配置一个时间段,每当一个服务实例启动时,请求方会向该实例发送一部分请求负载,并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达,就会退出慢启动模式。

在慢启动模式下,添加新的目标服务Pod时,避免新增Pod被大量请求击垮,这些新目标服务可以根据指定的加速期在接受其均衡策略的请求之前进行预热。

慢启动对于依赖缓存并且需要预热期才能以最佳性能响应请求的应用程序非常有用。在ASM下,您只需在服务对应的DestinationRule下的配置trafficPolicy/loadBalancer即可,需要注意的是:

  • loadBalancer:表示负载均衡器信息。类型限定于ROUND_ROBINLEAST_REQUEST负载均衡器。

  • warmupDurationSecs:表示Service的预热持续时间。如果设置,则新创建的服务端点在此窗口期间从其创建时间开始保持预热模式,并且Istio逐渐增加该端点的流量,而不是发送成比例的流量。

说明

慢启动要求应用在当前可用区的副本数不为0。例如:

  • 数据面集群只有一个可用区A,可用区A中当前有一个副本,启动第二个时,慢启动会生效。

  • 数据面集群有两个可用区A、B,当前应用只有一个副本,且位于可用区A,如果启动的第二个副本位于可用区B(一些调度器会默认采用跨可用区分布的策略),则不会触发慢启动。此时,如果再启动第三个副本,慢启动会生效。

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。

  1. 定义访问入口。

    1. 使用以下内容,创建bookinfo-gateway.yaml文件。

      展开查看bookinfo-gateway.yaml

      apiVersion: networking.istio.io/v1alpha3
      kind: Gateway
      metadata:
        name: bookinfo-gateway
      spec:
        selector:
          istio: ingressgateway
        servers:
        - port:
            number: 80
            name: http
            protocol: HTTP
          hosts:
          - "*"
      ---
      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: bookinfo
      spec:
        gateways:
          - bookinfo-gateway
        hosts:
          - '*'
        http:
          - match:
            - uri:
                exact: /productpage
            - uri:
                prefix: /static
            - uri:
                exact: /login
            - uri:
                exact: /logout
            - uri:
                prefix: /api/v1/products
            route:
              - destination:
                  host: productpage
                  port:
                    number: 9080
          - match:
            - uri:
                prefix: /reviews
            route:
              - destination:
                  host: reviews
                  port:
                    number: 9080
      
    2. 执行以下命令,部署bookinfo-gateway。

      kubectl apply -f bookinfo-gateway.yaml
  2. 创建Reviews服务。

    1. 使用以下内容,创建reviews.yaml文件。

      展开查看reviews.yaml

      apiVersion: networking.istio.io/v1beta1
      kind: DestinationRule
      metadata:
        name: reviews
      spec:
        host: reviews
        trafficPolicy:
          loadBalancer:
            simple: ROUND_ROBIN                        
    2. 执行以下命令,部署Reviews。

      kubectl apply -f reviews.yaml
  3. 开启网格拓扑, 持续访问入口网关地址。

    本文以通过hey命令发送压测请求10s为例。关于hey命令的下载和安装,请参见hey;关于开启和查看网格拓扑的具体操作,请参见查看应用的网格拓扑

    hey -z 10s -q 100 -c 4 http://${网关地址}/reviews/0

    调用拓扑示例图如下:image

步骤二:通过可观测数据查看Pod启动

  1. 登录ASM控制台

  2. 在左侧导航栏,选择服务网格 > 网格管理

  3. 网格管理页面,找到待配置的实例,单击实例的名称或在操作列中单击管理

  4. 在左侧导航栏单击可观测管理中心 > 监控指标

    • ASM实例版本为1.17.2.35以下:在监控指标页面,单击监控仪表页签,然后单击网格服务级别监控页签,选择对应的Reviews服务。

    • ASM实例版本为1.17.2.35及以上:在监控指标页面,单击网格工作负载级别监控页签,选择对应的reviews-v3工作负载,选择Reporter为source。

  5. 发送压测请求并观察监控数据。

    1. 在未开启预热功能的情况下,在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数从0扩容为1。

    2. 执行以下命令,发送压测请求入口网关。

      本文以发送压测请求120s为例。

      hey -z 120s -q 100 -c 4 http://${网关地址}/reviews/0
    3. 观察Prometheus监控的仪表盘数据。

      大约需要45s左右,reviews-v3 Pod将接收均衡的请求(具体时间会跟实际压测环境有关)。image

  6. 在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数缩容为0。

步骤三:启用预热功能

  1. 使用以下内容,更新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
  2. 执行以下命令,更新Reviews。

    kubectl apply -f reviews.yaml

步骤四:查看预热效果

  1. 开启预热功能后,在Kubernetes集群中将名为reviews-v3的Deployment部署的副本数从0扩容为1。

  2. 执行以下命令,发送压测请求入口网关。

    本文以发送压测请求150s为例。

    hey -z 150s -q 100 -c 4 http://${网关地址}/reviews/0
  3. 网格服务级别监控页签中,观察Prometheus监控的仪表盘数据。

    大概需要120s左右,reviews-v3 Pod将接收均衡的请求(具体时间会跟实际压测环境有关)。image由于Metrics的采集时间间隔限制,这条曲线并不平滑。实际上,到达reviews-v3 pod的流量是平滑增长的,如果您开启了Sidecar日志采集,可以在SLS中搜索这个Sidecar对应的日志,可以看到近5分钟的日志量。image在启用预热功能的情况下,每当一个服务实例启动时,请求方会向该实例发送一部分请求负载,并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达,就会退出慢启动模式。

    启用预热功能之后,需要2分30秒左右,流量将均衡地分布到v1、v2、v3版本。image

相关文档