AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

服务网格ASM使用FAQ之(2)：使用ASM实现服务慢启动模式以支持预热功能

2022-09-13 334
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
性能测试 PTS，5000VUM额度
应用型负载均衡 ALB，每月750个小时 15LCU
网络型负载均衡 NLB，每月750个小时 15LCU
简介： ### 背景在未启用慢启动预热能力时， 每当新目标Pod加入时，请求方都会向该Pod发送一定比例的流量， 不支持新 Pod 的渐进式流量增加。这对于需要一些预热时间来提供全部负载的服务可能是不可取的，并且可能会导致请求超时、数据丢失和用户体验恶化。作为一个实际示例，上述问题体现在基于 JVM 的 Web 应用程序中，这些应用程序使用水平 pod 自动缩放。当服务刚启动时，它会被大量请求淹没

背景

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

ASM服务预热功能介绍

ASM 在1.14 版本开始支持慢启动预热能力。简单介绍：
•慢启动模式又称渐进式流量增加，有助于克服上述问题。用户可以为他们的服务配置一个时间段，这样每当一个服务实例启动时， 请求方会向该实例发送一部分请求负载，并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达，它就会退出慢启动模式。
•在慢启动模式下，在添加新的目标服务Pod时，可以使得他们不会被大量请求压倒，这些新目标服务可以根据指定的加速期在接受其均衡策略的请求之前进行预热。
•慢启动对于依赖缓存并且需要预热期才能以最佳性能响应请求的应用程序非常有用。

对应在ASM 下，只需在服务对应的DestinationRule 下的配置trafficPolicy/loadBalancer即可，注意的是

  • loadBalancer的类型限定于ROUND_ROBIN 和 LEAST_REQUEST 负载均衡器。
  • warmupDurationSecs表示 Service 的预热持续时间。如果设置，则新创建的服务端点在此窗口期间从其创建时间开始保持预热模式，并且 Istio 逐渐增加该端点的流量，而不是发送成比例的流量。

示例如下：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: mocka
spec:
  host: mocka
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 100s
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

前提准备

Step1: 配置路由规则及确认应用运行

本示例中，为演示方便首先将review的v2和v3版本的Deployment副本数调整为0， 即在Kubernetes集群中将名为reviews-v2与reviews-v3的Deployment部署的副本数缩容为0。
同时， 确认在ASM中已经创建如下规则配置， 包括：

  • 用于定义访问入口的配置
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - bookinfo-gateway
  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
  • 定义reviews服务的配置
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews

在开启网格拓扑之后， 通过不断地访问入口网关地址，例如通过如下hey命令发送请求。采用hey 命令发送压测请求10s

hey 命令下载和安装参考链接： https://github.com/rakyll/hey 
hey -z 10s http://${网关地址}/productpage

可以看到正常的调用拓扑如下所示， 具体参考https://help.aliyun.com/document_detail/432495.html：
image.png

Step2: 通过可观测数据查看Pod启动

在ASM控制台中， 选择对应的ASM实例，在左侧导航栏选择可观测管理下的Prometheus监控，在右侧页面中选择 网格服务级别监控， 选择对应的reviews服务。

在未开启预热功能的情况下， 在Kubernetes集群中将名为reviews-v2的Deployment部署的副本数从0扩为1，采用hey 命令发送压测请求入口网关 。注意观察Prometheus监控的仪表盘数据, 大概需要15s左右的时间reviews-v2 Pod将接收均衡的请求（具体时间会跟实际压测环境有关）。
image.png

然后在Kubernetes集群中将名为reviews-v2的Deployment部署的副本数缩容为0。等待1分钟之后， 将开启预热功能。

Step3: 启用预热功能

更新名为reviews的DestinationRule，增加warmupDurationSecs值为120s， 即定义预热持续时间为120s 。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
      warmupDurationSecs: 120s

Step4: 通过可观测数据查看预热效果

类似地， 在开启了预热功能的情况下， 在Kubernetes集群中将名为reviews-v2的Deployment部署的副本数从0扩为1，采用hey 命令发送压测请求入口网关 。注意观察Prometheus监控的仪表盘数据, 大概需要45s左右的时间reviews-v2 Pod将接收均衡的请求（具体时间会跟实际压测环境有关）。
image.png

可以看到在启用预热功能的情况下， 每当一个服务实例启动时， 请求方会向该实例发送一部分请求负载，并在配置的时间段内逐步增加请求量。当慢启动窗口持续时间到达，它就会退出慢启动模式。

此外， 启用预热功能之后， 需要2分30秒左右， 流量均衡地分布到v1和v2版本。
image.png

Step5: 通过代理计数器查看预热效果

在查看服务预热效果之前， 操作以下两个步骤：

  1. 需要清空计数器的已有数据便于查看新增的计数值，执行如下命令：
## reviews-v1 版本对应Pod中的Sidecar代理计数器
kubectl exec reviews-v1-55b668fc65-jhxlj  -c istio-proxy -- curl localhost:15000/reset_counters -X POST

执行如下命令可以查看Sidecar代理中的计数器统计成功处理了多少次， 清空之后应当为0：

kubectl exec reviews-v1-55b668fc65-jhxlj  -c istio-proxy -- curl localhost:15000/stats |grep inbound |grep upstream_rq_200

可以看到类似结果输出：

cluster.inbound|8000||.upstream_rq_200: 0
  1. 将review的v2版本的Deployment副本数调整为0， 即在Kubernetes集群中将名为reviews-v2的Deployment部署的副本数缩容为0。

然后， 重新将在Kubernetes集群中将名为reviews-v2的Deployment部署的副本数从0扩为1，采用hey 命令发送压测请求入口网关 。并立即执行hey 命令同样发送压测请求20s：

hey -z 20s http://${网关地址}/productpage
Status code distribution:
  [200]    3260 responses
这表示通过hey 命令在20s 时间内成功发送了3260 个请求

然后对比reviews-v1 和 reviews-v2 两个pod ，可以看到reviews-v2 POD实例接受到的请求只占少量比例；

执行如下命令可以查看reviews-v1 中Sidecar代理中的计数器统计成功处理了多少次：

kubectl exec reviews-v1-55b668fc65-jhxlj  -c istio-proxy -- curl localhost:15000/stats |grep inbound |grep upstream_rq_200
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 20873    0 20873    0     0  19.9M      0 --:--:-- --:--:-- --:--:-- 19.9M
cluster.inbound|9080||.external.upstream_rq_200: 2927
cluster.inbound|9080||.upstream_rq_200: 2927

执行如下命令可以查看reviews-v2 中Sidecar代理中的计数器统计成功处理了多少次：

kubectl exec reviews-v2-858f99c99-j6jww   -c istio-proxy -- curl localhost:15000/stats |grep inbound |grep upstream_rq_200
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 30149    0 30149    0     0  28.7M      0 --:--:-- --:--:-- --:--:-- 28.7M
cluster.inbound|9080||.external.upstream_rq_200: 333
cluster.inbound|9080||.upstream_rq_200: 333

根据上述统计数据， 可以看到在前20s 因为在120s 的慢启动窗口期内，reviews-v2 Pod处理了少量请求（10% 左右）

慢启动窗口期之后测试， 再次清空reviews-v1、reviews-v2 的计数器。执行如下命令：

## reviews-v1 版本对应Pod中的Sidecar代理计数器
kubectl exec reviews-v1-55b668fc65-jhxlj  -c istio-proxy -- curl localhost:15000/reset_counters -X POST
## reviews-v2 版本对应Pod中的Sidecar代理计数器
kubectl exec reviews-v2-858f99c99-j6jww  -c istio-proxy -- curl localhost:15000/reset_counters -X POST

然后同样执行hey 命令发送压测流量20s， 再次执行如下命令查看reviews-v1与reviews-v2 中的Sidecar代理中的计数器统计成功处理了多少次：

kubectl exec reviews-v1-55b668fc65-jhxlj  -c istio-proxy -- curl localhost:15000/stats |grep inbound |grep upstream_rq_200
cluster.inbound|9080||.external.upstream_rq_200: 1600
cluster.inbound|9080||.upstream_rq_200: 1600
kubectl exec reviews-v2-858f99c99-j6jww   -c istio-proxy -- curl localhost:15000/stats |grep inbound |grep upstream_rq_200
cluster.inbound|9080||.external.upstream_rq_200: 1600
cluster.inbound|9080||.upstream_rq_200: 1600

可以看到在慢启动窗口时间之外，reviews-v1 和 reviews-v2 接受并处理了等量的请求数。

文章标签：
服务网格
容器服务Kubernetes版
性能测试
负载均衡
Java
Perl
容器
测试技术
Cloud Native
UED
监控
Kubernetes
缓存
Prometheus
关键词：
服务网格模式
服务网格服务
服务网格asm
服务网格 asm
服务网格功能
osswangxining
目录
相关文章
fazi
|
3月前
|
运维 Kubernetes 安全
利用服务网格实现全链路mTLS（一）：在入口网关上提供mTLS服务
阿里云服务网格（Service Mesh，简称ASM）提供了一个全托管式的服务网格平台，兼容Istio开源服务网格，用于简化服务治理，包括流量管理和拆分、安全认证及网格可观测性，有效减轻开发运维负担。ASM支持通过mTLS提供服务，要求客户端提供证书以增强安全性。本文介绍如何在ASM入口网关上配置mTLS服务并通过授权策略实现特定用户的访问限制。首先需部署ASM实例和ACK集群，并开启sidecar自动注入。接着，在集群中部署入口网关和httpbin应用，并生成mTLS通信所需的根证书、服务器证书及客户端证书。最后，配置网关上的mTLS监听并设置授权策略，以限制特定客户端对特定路径的访问。
fazi
135 2
阿里云基础设施.
|
14天前
|
Kubernetes 大数据 调度
使用Kmesh作为阿里云服务网格ASM Sidecarless模式数据面
阿里云服务网格ASM支持Sidecar和Sidecarless两种模式，本文介绍了如何在阿里云ACK集群中部署Kmesh作为Sidecarless数据面并连接ASM控制面。
阿里云基础设施.
28 3
游客bwdpfqtrj42km
|
25天前
|
Kubernetes 调度 容器
使用Kmesh作为阿里云服务网格ASM Sidecarless模式数据面
阿里云服务网格ASM支持Sidecar和Sidecarless两种模式，其中Sidecarless模式如Istio Ambient、ACMG和Kmesh等，可减少延迟和资源消耗。Kmesh基于eBPF技术，通过内核空间拦截流量，结合Waypoint Proxy处理L7流量，实现高效的服务治理。本文介绍了如何在阿里云ACK集群中部署Kmesh并连接ASM控制面，包括安装步骤、检查服务状态和流量调度示例。
游客bwdpfqtrj42km
77 0
土木林森
|
3月前
|
Prometheus Kubernetes 监控
打造无缝灾备新境界：运用服务网格ASM，将集群外服务无缝融入集群内服务，铸就高可用性坚盾！
【8月更文挑战第2天】随着微服务架构的应用，服务的高可用性变得至关重要。服务网格如阿里巴巴的ASM提供流量管理、服务发现等功能，支撑高可靠服务系统。本文介绍如何利用ASM实现集群外服务作为集群内服务的灾备方案，确保服务连续性。先决条件包括已部署ASM的Kubernetes集群环境及内外部的关键服务副本。通过定义服务条目、配置虚拟服务和目的地规则，可实现自动或手动故障转移。借助ASM的流量管理能力，确保服务高可用性和业务连续性。
土木林森
54 10
fazi
|
3月前
|
Kubernetes 安全 数据安全/隐私保护
利用服务网格实现全链路mTLS（二）：通过出口网关访问外部mTLS服务
阿里云服务网格（Service Mesh，简称ASM）提供了一个全托管式的服务网格平台，兼容Istio开源服务网格，简化服务治理，包括流量管理、服务间通信安全及网格可观测性。ASM出口网关统一管理网格内的出口流量，实现全链路加密通信与精细访问控制。本文介绍如何配置ASM出口网关以管理出口流量并发起mTLS通信，涉及配置ServiceEntry、创建出口网关、设置虚拟服务及目标规则等步骤，最终实现安全可控的mTLS服务访问。
fazi
154 3
fazi
|
3月前
|
Perl
如何利用服务网格ASM使用集群外服务做集群内服务的灾备
本文档指导您如何配置阿里云服务网格(ASM)以实现在多集群环境下，服务间的优先访问及故障转移策略。
fazi
115 2
阿里云云原生
|
5月前
|
Cloud Native 容器 Kubernetes
基于阿里云服务网格流量泳道的全链路流量管理（三）：无侵入式的宽松模式泳道
本文简要讨论了使用流量泳道来实现全链路流量灰度管理的场景与方案，并回顾了阿里云服务网格 ASM 提供的严格与宽松两种模式的流量泳道、以及这两种模式各自的优势与挑战。接下来介绍了一种基于 OpenTelemetry 社区提出的 baggage 透传能力实现的无侵入式的宽松模式泳道，这种类型的流量泳道同时具有对业务代码侵入性低、同时保持宽松模式的灵活特性的特点。同时，我们还介绍了新的基于权重的流量引流策略，这种策略可以基于统一的流量匹配规则，将匹配到的流量以设定好的比例分发到不同的流量泳道。
阿里云云原生
73530 16
基于阿里云服务网格流量泳道的全链路流量管理（三）：无侵入式的宽松模式泳道
阿里云基础设施.
|
5月前
|
负载均衡 Kubernetes 算法
服务网格 ASM 负载均衡算法全面解析
在本文中，笔者将解析服务网格的多种负载均衡算法的实现原理和使用场景，为服务网格负载均衡算法的选择提供参考。
阿里云基础设施.
71 0
蓝易云
|
6月前
|
运维 负载均衡 监控
如何构建Sidecarless模式的高性能服务网格
以上步骤可以帮助你构建一个Sidecarless模式的高性能服务网格。但是，请记住，每个应用都有其特定的需求和约束，你可能需要根据你的具体情况进行调整。
蓝易云
69 1
阿里云云原生
|
6月前
|
存储 机器学习/深度学习 负载均衡
模型服务网格：云原生下的模型服务管理
模型服务网格：云原生下的模型服务管理
阿里云云原生
78533 11
模型服务网格：云原生下的模型服务管理

热门文章

最新文章

  • 1
    Kubernetes上的服务网格 Istio - 分布式追踪篇
  • 2
    动态代理解释-JDK,CGLIB,JAVASSIST,ASM
  • 3
    11gR2 RAC ASM启动揭秘
  • 4
    AIX平台下磁盘的PVID对ASM磁盘的破坏
  • 5
    ASM_Oracle ASM的概念（概念）
  • 6
    服务网格规模化应用下的Istio Sidecar配置管理挑战与实践｜IstioCon 2022
  • 7
    ASM REACTING TO PARTITION ERRORS [ID 1062954.1]
  • 8
    RAC 下使用DBCA 建立ASM出错（ORA-15032，ORA-15063）
  • 9
    使用eBPF加速阿里云服务网格ASM
  • 10
    服务网格实施周期缩短 50%，丽迅物流基于阿里云 ACK 和 ASM 的云原生应用管理实践
  • 1
    探索微服务架构下的服务网格
    59
  • 2
    如何构建Sidecarless模式的高性能服务网格
    69
  • 3
    探索微服务架构下的服务网格（Service Mesh）实践
    193
  • 4
    Golang深入浅出之-Go语言中的服务网格（Service Mesh）原理与应用
    454
  • 5
    探索微服务架构下的服务网格(Service Mesh)实践之路
    91
  • 6
    探索微服务架构下的服务网格(Service Mesh)实践
    83
  • 7
    【专栏】随着技术发展，未来将探索服务网格、容器化和云原生技术，以提升微服务架构的效能
    107
  • 8
    asm.js 的异步脚本
    51
  • 9
    使用ACME CA为ASM网关签发证书
    223
  • 10
    Resized LUNS Not Recoginzed by ASM Diskgroup (Doc ID 2973897.1)
    48

    • 相关课程

    更多
  • 深度解读服务网格的未来
  • Nacos 服务网格生态
  • 服务网格技术最佳实践
  • 如何使用Kubernetes监控定位慢调用

    • 相关电子书

    更多
  • 基于英特尔®架构的阿里云服务网格ASM技术加速应用服务加密通
  • 阿里云总监课第五期第四节：从容器到云原生–服务网格
  • 低代码开发师（初级）实战教程

    • 相关实验场景

    更多
  • 基于MSE-Nacos实现服务的动态发现和配置动态管理
    • 下一篇
    无影云桌面