引言
在Shopify ，我们正在将Istio部署为服务网格。 原则上，所有内容都适合，但有一件除外： 它很昂贵 。
Istio 已发布的基准说：
使用Istio 1.1，该代理每秒每1000个请求消耗约0.6个vCPU（虚拟内核）。
对于服务网格中的第一个区域（连接的每一侧有2个代理），我们将仅拥有1200个代理核心，速率为每秒一百万个请求。 根据Google的费用计算器，对于n1-standard-64配置，您可以获得约40美元/月/内核，也就是说，仅此区域一个月的费用就超过了50,000美元，每秒处理100万个请求。
Ivan Sim（ Ivan Sim ） 清楚地比较了去年的服务网格延迟，并承诺在内存和处理器上相同，但是失败了：
显然，values-istio-test.yaml将严重增加处理器请求。 如果我正确计算了所有内容，则控制面板需要约24个处理器内核，每个代理服务器需要0.5个CPU内核。 我没那么多。 当有更多资源分配给我时，我将重复测试。
我想亲自看看Istio的性能与另一个开源服务网格Linkerd有何相似之处 。
服务网格安装
我在SuperGloo群集中安装的第一件事是 ：
$ supergloo init installing supergloo version 0.3.12 using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz configmap/sidecar-injection-resources created serviceaccount/supergloo created serviceaccount/discovery created serviceaccount/mesh-discovery created clusterrole.rbac.authorization.k8s.io/discovery created clusterrole.rbac.authorization.k8s.io/mesh-discovery created clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created deployment.extensions/supergloo created deployment.extensions/discovery created deployment.extensions/mesh-discovery created install successful!
我使用SuperGloo是因为它极大地简化了服务网格的启动。 我几乎无事可做。 在生产中，我们不使用SuperGloo，但它是完成类似任务的理想选择。 我只需要对每个服务网格应用几个命令。 我使用了两个群集进行隔离-一个用于Istio和Linkerd。
实验是在Google Kubernetes Engine上进行的。 我使用了Kubernetes 1.12.7-gke.7和具有自动节点缩放功能（最少4个，最多16个）的n1-standard-4节点池。
然后，我从命令行安装了两个服务网格。
链接器优先：
$ supergloo install linkerd --name linkerd +---------+--------------+---------+---------------------------+ | INSTALL | TYPE | STATUS | DETAILS | +---------+--------------+---------+---------------------------+ | linkerd | Linkerd Mesh | Pending | enabled: true | | | | | version: stable-2.3.0 | | | | | namespace: linkerd | | | | | mtls enabled: true | | | | | auto inject enabled: true | +---------+--------------+---------+---------------------------+
然后Istio：
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true +---------+------------+---------+---------------------------+ | INSTALL | TYPE | STATUS | DETAILS | +---------+------------+---------+---------------------------+ | istio | Istio Mesh | Pending | enabled: true | | | | | version: 1.0.6 | | | | | namespace: istio-system | | | | | mtls enabled: true | | | | | auto inject enabled: true | | | | | grafana enabled: true | | | | | prometheus enabled: true | | | | | jaeger enabled: true | +---------+------------+---------+---------------------------+
崩溃循环持续了几分钟，然后控制面板稳定下来。
（注意：SuperGloo当前仅支持Istio1.0.x。我使用Istio 1.1.3重复了该实验，但没有发现任何明显的区别。）
设置Istio的自动部署
为了让Istio安装Sidecar Envoy，我们使用Sidecar注入器MutatingAdmissionWebhook 。 我们不会在本文中谈论他。 我只能说这是一个控制器，它监视所有新Pod的访问，并动态添加sidecar和initContainer，后者负责iptables任务。
我们在Shopify编写了访问控制器以实现Sidecar，但在此基准测试中，我采用了Istio随附的控制器。 默认情况下，当名称空间中存在istio-injection: enabled快捷方式时，控制器将注入sidecar：
$ kubectl label namespace irs-client-dev istio-injection=enabled namespace/irs-client-dev labeled $ kubectl label namespace irs-server-dev istio-injection=enabled namespace/irs-server-dev labeled
配置Linkerd自动部署
要配置Linkerd sidecar的实现，我们使用批注（我通过kubectl edit手动添加了批注）：
metadata: annotations: linkerd.io/inject: enabled
$ k edit ns irs-server-dev namespace/irs-server-dev edited $ k get ns irs-server-dev -o yaml apiVersion: v1 kind: Namespace metadata: annotations: linkerd.io/inject: enabled name: irs-server-dev spec: finalizers: - kubernetes status: phase: Active
容错模拟器Istio
我们制作了Istio容错模拟器来试验Shopify独有的流量。 我们需要一个工具来创建一个任意拓扑，该拓扑将通过动态调整来模拟特定工作负载，从而代表我们服务图的特定部分。
在Flash销售期间，Shopify基础架构承受着沉重的负担。 同时，Shopify 建议卖方更频繁地进行此类销售 。 大型客户有时会警告计划中的限时抢购。 其他人在白天或晚上的任何时候都为我们意外地花费了它们。
我们希望容错模拟器能够对与过去Shopify基础架构超负荷的拓扑和工作负载相匹配的工作流进行建模。 使用服务网格的主要目的是我们需要网络级别的可靠性和容错能力，对于我们来说，重要的是，服务网格可以有效地处理先前中断服务运行的负载。
故障转移模拟器基于充当服务网格节点的工作节点。 可以在启动时静态配置工作节点，也可以通过REST API动态配置工作节点。 我们使用工作节点的动态调整以回归测试的形式创建工作流。
这是此过程的示例：
- 我们以
bar服务启动10台服务器，在100毫秒后返回200/OK响应。 - 我们启动10个客户端-每个客户端每秒向
bar发送100个请求。 - 每隔10秒，我们将删除1台服务器，我们会在客户端上监视
5xx错误。
在工作流程的最后，我们研究日志和指标并检查测试是否通过。 这是我们了解服务网格的性能并进行回归测试以测试我们对容错性的假设的方式。
（注意：我们正在考虑为Istio容错模拟器打开源代码，但我们还没有准备好。）
用于服务网格基准测试的Istio容错模拟器
我们配置模拟器的几个工作节点：
irs-client-loadgen ：3个副本，每秒向irs-client发送100个请求。irs-client ：接收请求的3个副本等待100 ms，然后将请求重定向到irs-server 。irs-server ：3个副本，在100毫秒后返回200/OK 。
使用此配置，我们可以测量9个端点之间的稳定流量。 irs-client-loadgen和irs-client-loadgen irs-server Sidecar每秒接收100个请求，而irs-client -200（传入和传出）。
因为没有Prometheus集群，所以我们通过DataDog跟踪资源使用情况。
结果
控制面板
首先，我们检查了CPU消耗。
Linkerd控制面板〜22M
Istio控制面板：约7.5亿核
Istio控制面板使用的处理器资源是Linkerd的大约35倍 。 当然，所有设置都是默认设置，直方遥测会消耗大量处理器资源（您可以通过放弃某些功能来禁用它）。 如果您删除此组件，它仍然会超过100个多核，是Linkerd的4倍 。
Sidecar代理
然后，我们检查了代理的使用。 对请求数量的依赖关系应该是线性的，但是对于每个小车来说，都会有一些影响曲线的开销。
Linkerd：对于irs-client为〜100Mnuclear，对于irs-client-loadgen为〜50Mnuclear
结果看起来合乎逻辑，因为客户端代理收到的流量是loadgen代理的两倍：对于来自loadgen的每个传出请求，客户端都有一个传入和一个传出。
Istio / Envoy：约155个百万富翁为irs-client，约75个百万富翁为irs-client-loadgen
对于Istio边车，我们看到类似的结果。
但总体而言，Istio / Envoy代理比Linkerd消耗的处理器资源多约50％ 。
我们在服务器端看到了相同的方案：
Linkerd：irs服务器约50个多核
Istio / Envoy：用于IRS服务器的〜80多核
在服务器端，Istio / Envoy的辅助车比Linkerd消耗的处理器资源多约60％ 。
结论
在我们的模拟工作负载上，Istio Envoy代理比Linkerd多消耗了50％以上的CPU。 Linkerd控制面板比Istio消耗更少的资源，尤其是对于主要组件。
我们仍在考虑如何降低这些成本。 如果您有任何想法，请分享！