helm安装istio_Istio的性能实测@KubeCon 2019 Day2

大魏说：

Topic的Speaker是IBM的两位专家。、

Istio是一个迭代非常快的开源项目，在2019年初1.0版本发布，如今最新版本已经是1.2。在1.1版本中，我进行过一些测试，Istio绝大多数的功能是没问题的。但在测试限流的时候，有时候不生效。Istio1.1的限流需要借助于memqouta或redisqouta。前者不能做HA，后者需要在K8S中部署redis(通过缓存做限流)。希望在1.2版本这个功能能够更健壮。注入sidecar会造成性能下降。这也是红帽在OCP中不启动Sidecar的全自动注入的方式原因。

Istio分为控制平面和数据平面。数据平面是pod中的sidercar，实际上就是代理。有了代理，好处是可以通过代理用声明式的配置调整路由等策略。缺点是代理必然会带来性能的损耗。Istio官方公布的数据，在Istio内部微服务之间通讯，端到端的延迟会增加10毫秒(出栈2毫秒，入栈8毫秒)。整体性能损耗30%左右。此外，在很多Istio的测试中，很多同学表示Istio的并发上不去。之前我由于缺乏大规模的测试环境，无法做性能测试，因此没找到太多的方法。IBM两位专家分享的内容是很有借鉴意义的。

下图可以看到，测试是基于做了sidecar注入的6000个pod(3000个service)，和4000个未被注入sidecarpod(1000个service)做的。两类pod分别未在100个namesapce里。当集群中部署了4000个未注入sidecar的pod时，我们可以看到，由于pod未和istio发生任何关系，Istio占用资源不高。

当6000个注入sidecar的pod也创建完毕以后，Istio组件占用资源的数量激增。由于启用了HPA，所以istio-polot自动做了横向扩展，每个实例占用大量内存，但是，Istio和envoy的连接数远远没到6000。也就是说，Istio把资源占了，但压力上不去。

解决这个问题的第一个方法是启用命名空间隔离。这是istio1.1中的功能。这个功能会创建一个全局的Istio命名空间，负责存放istio组件，然后将不同的受控微服务放到不同的命名空间，这些命名空间之间是相互隔离的。但他们都可以和全局的Istio命名空间之间通信。这样做的好处是减少微服务之间不必要的交互，但前提是需要做好微服务之间的规划。

除此之外，IBM的专家们在每一个namespace中创建一个ingressgateway。默认情况下，一个Istio配置一个ingressgateway，作为微服务流量的入口。如果部署到Openshift上，会自动在router上创建ingressgateway的路由。这样入口流量会先经过router再经过ingressgateway。如果我们在每个namespace中都配置一个ingressgateway，那么只需要在router上进行控制即可。这样做的好处是降低全局ingressgateway的瓶颈。当然，此时如果入口流量过大，router同样可能存在性能的瓶颈。这时候可以配置多个router，在前段配置硬件负载均衡器。

基于上面的调整，进行压力测试：

将注入sidecar和未注入sidecar的pod性能进行对比，注入sidecar会造成性能下降26%。低于官方的数字。

最佳实践如下：

1. 启用命名空间隔离

2. 每个命名空间创建一个ingressgateway

3. 禁用policy组件(这个配置，在目前Istio on OpenShift上是建议打开的disablePolicyChecks:false,负责会造成一个istio配置不生效。因此这个建议需要进一步在OpenShift上验证)

4. 调整普罗米修斯的参数以便减少内存和CPU消耗。

Istio参数调整建议如下。如果是在OCP上安装Istio，可以参照如下文档。由于红帽安装Istio的方式是通过Operator(社区目前大多采用helm方式安装)，因此参数与下面列的并不是所有都可以调整，需要进一步在OCP上验证。https://docs.openshift.com/container-platform/3.11/servicemesh-install/servicemesh-install.html#custom-resource-parameters