idou老师教你学Istio 04:Istio性能及扩展性介绍

Istio的性能问题一直是国内外相关厂商关注的重点,Istio对于数据面应用请求时延的影响更是备受关注,而以现在Istio官方与相关厂商的性能测试结果来看,四位数的qps显然远远不能满足应用于生产的要求。从发布以来,Istio官方也在不断的对其性能进行优化增强。同时,Istio控制面的可靠性是Istio用于生产的另一项重要考量标准,自动伸缩扩容,自然是可靠性保证的重要手段。下面我们先从性能测试的角度入手,了解下Istio官方提供的性能测试方法与基准,主要分为以下四个方面展开。

一、函数级别测试

Istio提供了函数级别的性能测试用例,开发者可用更好的有针对性的进行性能优化,这里不做展开,感兴趣的朋友可用参考:

https://raw.githubusercontent.com/istio/istio/release-1.0/mixer/test/perf/singlecheck_test.go

二、端到端测试基准

为了更好的跟踪Istio的性能问题,Istio提供了一个专门用于Isito性能测试的测试工具——Fortio。你可以通过kubernetes集群,轻而易举的将Forito部署起来,测试工具的安装链接如下:

https://github.com/istio/istio/tree/release-1.0/tools#istio-load-testing-user-guide

下图是测试工具的组织结构图,其中上半部分为Istio服务网格管理的两个服务S1与S2,其中S1服务关掉了mixer上报功能(mixer遥测功能实现方案一直备受争议,业界普遍认为sidecar向mixer上报遥测数据一定程度上损害了sidecar的请求转发能力),请求通过ingressgateway流入系统,再经由sidecar分发到各个服务,是典型的Istio服务访问方式。下半部分为经典的kubernetes集群中的服务访问方式,请求经由k8s的proxy的转发,负载均衡到各个pod。两者的对比也就展示了Istio访问模式与经典模式相比,性能方面的损耗,下面介绍一下Fortio的几个功能点:

a)Fortio是一个快速,小巧,可重复使用,可嵌入的go库以及命令行工具和服务器进程,该服务器包括一个简单的Web UI和结果的图形表示;

b)Fortio也是100%开源的,除了go和gRPC之外没有外部依赖,能够轻松地重现Istio官方性能测试场景也能适应自己想要探索的变体或场景;

c)Fortio以每秒指定的qps对服务进行压测,并记录影响时延的直方图并,计算百分比,平均值,tp99等统计数值。

Fortio在kubernetes中的安装步骤:

kubectl -n fortio run fortio --image=istio/fortio:latest_release --port=8080

kubectl -n fortio expose deployment fortio --target-port=8080 --type=LoadBalancer

三、真实场景下测试基准

Acmeair(又名BluePerf)是一个用Java实现的类似客户的微服务应用程序。此应用程序在WebSphere Liberty上运行,并模拟虚拟航空公司的运营。

Acmeair由以下微服务组成:

a) Flight Service检索航班路线数据。预订服务会调用它来检查奖励操作的里程(Acmeair客户忠诚度计划)。

b) 客户服务存储,更新和检索客户数据。它由Auth服务用于登录和预订服务用于奖励操作。

c) 预订服务存储,更新和检索预订数据。

d) 如果用户/密码有效,Auth服务会生成JWT。

e) 主服务主要包括与其他服务交互的表示层(网页)。这允许用户通过浏览器直接与应用程序交互,但在负载测试期间不会执行此操作。

这个模拟航空公司的运营系统demo,能够更好的模拟在实际生产环境中的Istio应用,感兴趣的朋友可用到如下链接了解一下:https://github.com/blueperf

四、每日构建自动化测试结果

Istio与IBM会对Istio的每日构建版本进行性能测试,并将测试结果公布出来,供大家参考。自动化测试包括端对端用例fortio以及应用级别bluePerf的性能测试结果。对Isito性能感兴趣,但没有时间精力进行性能测试的朋友,可以关注一下官方的每日性能测试结果,跟踪Istio性能优化的最新进展。

https://fortio-daily.istio.io/

https://ibmcloud-perf.istio.io/regpatrol/

这里,我们一起来看下IBM的性能测试结果,并进行一下分析。

IBM的性能测试对比主要包括三部分,第一部分是各个Release版本之间的性能比较,其中列出了0.6.0,0.7.1,0.8.0版本的性能测试情况,这里的指标数据是qps,可以看到,前三个版本之间的数据十分相近,没有比较大的提升,且Istio与IngressOnly之间的对比可以看出,Istio造成了相当大的性能损耗,大约只能达到无Istio时百分之三十多的qps,可见,性能方面Istio还需要进一步优化。

Row Release (A)Istio Full (B) No Mixer (C) Ingress Only (A)/(C) % (B)/(C) %
1 0.6.0 1307 1987 3804 34.4 52.2
2 0.7.1 1294 2050 3671 35.2 55.8
3 0.8.0 1335 2222 3708 36.0 59.9

第二部分是当前release每日构建版本的性能情况,可以对比出每天的修改对性能方面的影响,这里我们列出一部分,更详细的信息大家可以到相应链接中查看,可以看到近期每日构建版本相较于1.0基线版本,有了一定的提升。

最后一部分是master分支的每日构建性能测试结果。可以看到,最新的master分支的性能测试结果,相较基线版本已经有了较大的提升,但是QPS损耗严重的问题依然存在,同时,千级别的QPS也不能真正满足生产需求,我们期待Istio的发展与进步。

五、Isito的可靠性与可扩展性

对控制面各组件的作用作用及故障影响进行了汇总,结果如下:

组件 作用及故障影响
istio-ingressgateway 对外流量入口,该组件挂掉将导致整个应用服务无法从外部访问,建议设置多实例,增强可靠性
istio-telemetry Mixer 相关组件,用于采集envoy上报的遥测数据,该组件挂掉将导致各监控运维插件无法采集到数据,同时,该组件在高并发情境下,会承受较大负荷,建议设置为多实例,增强可靠性
istio-policy Mixer 相关组件,用于与envoy交互,check需要上报的数据,确定缓存内容,挂掉会影响check相关功能
istio-pilot 控制sidecar中envoy的启动与参数配置,即流量规则实际下发者,挂掉将会导致新策略配置失效
istio-sidecar-injector 用于实现sidecar自动注入功能,挂掉将会导致sidecar无法自动注入,同时,若注入策略设置为必须注入(policy为Fail),则会导致新creating的pod无法启动
istio-citadel 用于安全相关功能,挂掉则会导致认证,安全相关功能失效

a) 考量到Istio控制面的可靠性,以及对资源的有效利用,建议将重要组件设置为多实例,包括:

● ingressgateway:作为外部流量入口,服务网格管理的所有服务的对外流量,都要经过gateway才能进入到服务网格内部,与业务逻辑强相关,建议配置为多实例;

● mixer:遥测数据的搜集端,用于汇总服务网格内所有服务上报的日志、监控数据,处理数据量巨大,建议设置为多实例,并给予更多资源配置;

● 其他控制面组件运行压力并不大,可根据需要自行调整实例数。

b) 容器自动扩缩容,Istio为主要组件gateway,pilot与mixer设置了自动扩缩容策略,且策略可以在安装时配置,我们以pilot为例看一下其自动扩缩容配置,以CPU占用率55%作为阈值,进行pod实例数的扩缩容侧率:

c) 高可用(HA),可根据需要,为Istio控制面组件设置亲和性策略,使相同控制面组件的多个不同pod运行不同node上,确保Istio控制面的高可用状态,下面以pilot为例,Istio为其增加了节点反亲和策略,使pod尽可能不运行在相同架构操作系统的节点上,大家可根据需要,自行增加亲和与反亲和策略。

d) 健康检查,Istio也为控制面组件配置了健康检查策略,以保证控制面组件异常时,k8s能够将其重新拉起,同样以sidecarinjector为例,设置了启动健康检查readinessProbe与运行时健康检查livenessProbe,以确保容器正常运行:

六、总结

再次说明一下,性能与可靠性是Istio生产可用至关重要的一环,功能方面Istio已经做的十分强大,并在不断的完善发展中,但在性能与可靠性方面,Istio还有很长的路要走。其中微服务sidecar的路由转发与mixer遥测功能对请求时延的影响,是摆在Istio性能提升前面的两道障碍,我们共同努力,共同关注,望Istio早日成熟,发展壮大,扬帆起航。

原文地址:http://blog.51cto.com/14051317/2345028

时间: 2024-08-04 02:32:30

idou老师教你学Istio 04:Istio性能及扩展性介绍的相关文章

idou老师教你学Istio 07: 如何用istio实现请求超时管理

前言 在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理.看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了,当然还存在部分被idou老师的文采刚吸引过来的新同学. 下面先简单的介绍一下Bookinfo这个样例应用整体架构,以便我们更好地

idou老师教你学Istio11 : 如何用Istio实现流量熔断

在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力.今天,将向大家介绍如何用Istio实现流量熔断. 熔断机制是创建弹性微服务应用程序的重要模式.熔断可以帮助您自由控制故障影响的范围.网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景. 在接下来的任务中,idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断,以及背后的原理. 首先,我们需要添加一个应用程序来模拟访问网络中的通信.接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中,然

idou老师教你学istio:监控能力介绍

经过了一年多的开发和测试,Istio于北京时间7月31日发布了1.0版本,并且宣布1.0版本已经可以成熟的应用于生产环境.对于istio的各项主要功能,之前的文章已经介绍的非常详细,并且还会有更多的文章来分析原理和实践功能.今天我们主要介绍的服务是istio流量监控能力.我们知道每个pod内都会有一个Envoy容器,其具备对流入和流出pod的流量进行管理,认证,控制的能力.Mixer则主要负责访问控制和遥测信息收集.如拓扑图所示,当某个服务被请求时,首先会请求istio-policy服务,来判定

idou老师教你学Istio06: 如何用istio实现流量迁移

概要 流量迁移是流量管理的一个重要功能.istio提供的流量管理功能将流量从基础设施扩展中解耦,支持动态请求路由,故障注入.超时重试.熔断和流量迁移等.流量迁移的主要目的是将流量从微服务的某一版本的逐步迁移至另一个版本,如在新旧版本之间进行流量切换.本文通过一个简单的用例介绍如何使用istio进行流量迁移. 本文使用一个bookinfo的典型例子.通过istio的命令配置规则,将流量从reviews的版本v1逐步迁移到版本v3.在下面的例子中,应用基于权重路由配置,将百分百路由在reviews:

idou老师教你学Istio 08: 调用链埋点是否真的“零修改”?

本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式.并基于Istio中埋点的原理解释来说明:为了输出一个质量良好的调用链,业务程序需根据自身特点做适当的修改,即并非官方一直在说的完全无侵入的做各种治理.另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式. Istio一直强调其无侵入的服务治理,服务运行可观察性.即用户完全无需修改代码,就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集.原文是这样描述的: Istio

idou老师教你学Istio12 : Istio 实现流量镜像

微服务为我们带来了快速开发部署的优秀特性,而如何降低开发和变更的风险成为了一个问题.Istio的流量镜像,也称为影子流量,是将生产流量镜像拷贝到测试集群或者新的版本中,在引导实时流量之前进行测试,可以有效地降低版本变更风险. 流量镜像有以下优点: 1.当流量镜像到不同的服务时,会发生在请求的关键路径之外,这样流量镜像产生的任何问题都不会影响到生产: 2.忽略对任何镜像流量的响应; 流量被视为"即发即忘",这样就不会干扰到正常的生产流量的响应: 3.当流量被镜像时,请求将通过其主机/授权

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness: liveness探针用来侦测什么时候需要重启容器.比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用. readiness探针用来使容器准备好接收流量.当所有容器都ready时被视为pod此时ready.比如说用这种信号来控制一个后端服务,当pod没有到ready状态时,服务会从负载均衡被移除. 使用场景: liveness

idou老师教你学Istio 15:Istio实现双向TLS的迁移

在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份.保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统.本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS. 使用场景 在部署了Istio的集群中,使用人员刚开始可能更关注功能性,服务之间的通信配置的都是明文传输,当功能逐渐完善,开始关注安全性,部署有sidecar的服务需要使用双向TLS进行安全传输,但服务不能中断,这时,一个可取的方式就是进行双向TLS的迁移.

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

摘要使用 Istio 可以很方便地实现微服务间的访问控制.本文演示了使用 Denier 适配器实现拒绝访问,和 Listchecker 适配器实现黑白名单两种方法. 使用场景 有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务. 访问控制属于策略范畴,在 Istio 中由 Mixer 组件实现. Mixer拓扑图,来源官方文档 如上图所示,服务的外部请求会被 Envoy 拦截,每个经过 Envoy 的请求都会调用 Mixer,为 Mixer