Service Mesh - Istio 1.5 拥抱单体，简化

2021-04-27 本文已影响0人 CatchZeng

原文：https://makeoptim.com/service-mesh/istio1-5

上一篇向大家介绍了 Service Mesh 的代表 Istio。并且介绍了 Istio 的架构，在文中我注解了1.5 版本去掉了 Mixer 组件。 Istio 1.5 是一个具有“重建”性的版本。以往，Istio 的性能和易用性一直是被吐槽的。从 Istio 1.5 可以看出，Istio 团队开始正视这个问题，并在此版本中重建了控制平面，拥抱单体，简化了 Istio 的体系架构，改善了操作体验。

Istio 1.5 introduces the Istiod binary, which significantly simplifies Istio’s architecture, improving operational experience. – By Steven Dake

架构

在架构上，Istio 1.5 重建了控制平面，将原有的多个组件整合为一个单体结构 istiod，并废弃了 Mixer 组件。

istiod

istiod 是微服务架构模型的逆转。要了解 istiod 如何改善 Istio，让我们看一下它之前的结构。

Istio 1.4 控制平面包括五个服务和可扩展性插件：

Sidecar 自动注入。由 Sidecar-Injector 提供（未图示）。
可扩展性。由 Mixer 提供（组织遥测和组织策略服务）。
可扩展性插件。由 Mixer Adapter 插件提供。
Sidecar 代理配置生成和服务。由 Pilot 提供。
安全。由 Citadel 提供。
验证。由 Galley 提供。

Istio 1.5 将控制平面重组为一项服务，并重新实现了可扩展性：

istiod：提供代理 Sidecar 自动注入，网格计算，安全性和验证。
数据平面：Mixer Adapater 插件作为 Envoy 插件在网格中重新实现。

如下图所示，Istio 1.5 的体系结构得到了简化：

需要注意的一点是，原有的多组件并不是被完全移除，而是在重构后以模块的形式整合在一起组成了 istiod。

为什么选择 Istiod

控制平面的操作更轻松。简化的体系结构使网格管理员和操作员可以更轻松地控制和监视 Istio 控制平面。istiod 与 Istio 1.4 中的六到七个服务相比，监视一项服务要容易得多。
提高性能。在 Istio 的其他版本中，通过网络进行了大量的控制间组件通信，这导致了性能问题。istiod 减少了组件数量，因此对性能产生积极影响。
减少内部 API 占用空间。以前的微服务实现中很多都包含冗余代码。通过删除此冗余代码（每个微服务通常用于配置）来改进 Istio。

功能更新

Istio 1.5 不仅仅简化了架构，同时也添加了新功能、优化性能、修复了一些 Bug。

流量管理

ServiceEntry 通过避免不必要的完全推送提升了性能。#19305
修复了 Envoy sidecar readiness 探针不一致问题。#18164
通过局部更新的方式改善了通过 xDS 进行的 Envoy 代理配置更新的性能。#18354
添加了通过 DestinationRule 为每个目标服务配置本地负载均衡设置的选项。#18406
修复了Pod崩溃会触发过多的Envoy代理配置推送的问题。#18574
修复了应用调用自己的问题。#19308
添加了 Istio CNI 时对 iptables 增加了故障检测。#19354
在 DestinationRule 添加了 consecutiveGatewayErrors 和 consecutive5xxErrors 作为异常检测选项。#19771
提升了 EnvoyFilter 匹配性能。#19786
添加了对 HTTP_PROXY 协议的支持。#19919
改进了 iptables 设置，默认使用 iptables-restore。#18847
通过过滤无用集群，提升了 Gateway 的性能。#20124

安全

稳定版添加 SDS，并默认开启。它为 Istio Envoy 代理提供身份配置。
添加 Beta 认证 API。新 API 分为 PeerAuthentication 和 RequestAuthenticaiton，面向工作负载。
在授权策略中添加了拒绝语义和排除匹配。
Beta 版本默认开启自动 mTLS。
Node agent 和 Pilot agent 合并，移除了 Pod 安全策略的需要，提升了安全性。
合并 Citadel 证书发放功能到 Istiod。
支持 Kubernetes first-party-jwt 作为集群中 CSR 认证的备用 token。
通过 Istio Agent 向 Prometheus 提供密钥和证书。
添加了支持 Istio CA 和 Kubernetes CA 来为控制平面提供证书，通过配置 values.global.pilotCertProvider。

遥测

对 v2 版本添加了 TCP 协议支持。
在指标和日志中支持添加 gRPC 响应状态码。
支持 Istio Canonical Service
改进 v2 遥测流程的稳定性。
为 v2 遥测的可配置性提供 alpha 级别的支持。
支持在 Envoy 节点的元数据中添加 AWS 平台的元数据。
更新了 Mixer 的 Stackdriver 适配器，以支持可配置的刷新间隔来跟踪数据。
支持对 Jaeger 插件的 headless 收集服务。
修复了 kubernetesenv 适配器以提供对名字中有.的 Pod 的支持。
改进了 Fluentd 适配器，在导出的时间戳中提供毫秒级输出。

配置管理

用 IstioOperator API 替代了 IstioControlPlane API。
添加了 istioctl operator init 和 istioctl operator remove 命令。
添加缓存改善了调和速度。

istioctl

istioctl analyze 转为稳定特性。
添加了各种分析器： mTLS、JWT, ServiceAssociation, Secret, sidecar image, port name and policy deprecated 等分析器。
为 RequestAuthentication 添加了更多的验证规则。
| 添加新标记 -A | –all-namespaces 给 istioctl analyze，来分析整个集群。 |
添加通过 stdin 到 istioctl analyze 的内容分析。
添加 istioctl analyze -L 显示所有可用分析列表。
添加从 istioctl analyze 抑制信息的能力。
为 istioctl analyze 添加结构化格式选项。
为 istioctl analyze 的输出添加对应的文档链接。
通过 Istio API 在分析器中提供标注方法。
istioctl analyze 可以基于目录加载文件。
istioctl analyze 尝试将消息与它们的源文件名关联。
istioctl analyze 可打印命名空间。
istioctl analyze 默认分析集群内资源。
修复分析器抑制集群级别资源消息的 bug。
为 istioctl manifest 添加多文件支持。
替换 IstioControlPlane API 为 IstioOperator API。
为 istioctl dashboard 添加选择器.
为 istioctl manifest –set 标记添加切片和列表支持。
添加了 docker/istioctl 镜像

小结

Istio 1.5 是一个“重建”性的版本。拥抱单体，简化架构，重建了整个控制平面，迎来了全新的 istiod；废弃了 Mixer，提高了性能。 Istio 1.5 的重建，不禁让我想起过早的优化是万恶之源。

Donald Knuth 1974 年在 ACM Journal 上发表的文章 “Structured Programming with go to Statements” 中写道：

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Istio

简言之，没有量化的性能测试检测到真正的性能问题之前，在代码层面各种炫技式优化，不仅可能提升不了性能，反而更会导致更多 bugs。而这些 bugs，在我看来不仅仅是代码上的问题，还包括可维护性、复杂性、问题诊断能力等。这顺应了一句老话，“永远没有完美的架构，只有最合适的架构”。不单单产品设计的时候，需要考虑用户。软件设计也需要考虑用户（可能是运维、团队新人等），更何况，软件本身就是一种产品。产品需要有用户使用才能产生价值，软件设计亦然。

在重建的同时，Istio 团队不忘持续优化和引入新的功能。我相信，Istio 一定会越来越成熟，社区一定会越来越火。让我们一起期待，Istio 的下一次更新。