深度剖析 | Istio v1.1 正式发布

Posted 2021-04-13 K8sMeetup社区

编辑：小君君（才云）、bot（才云）

技术校对：星空下的文仔（才云）、四石（才云）

北美时间 2019 年 3 月 19 日，Istio v1.1 正式发布。 继 1.0 版本发布后，Istio 先后发布了 6 个补丁来完善相关功能。8 个月后，1.1 版本终于现世，引起了国内外用户的强烈关注。

Istio 是一种降低云原生部署复杂性的解决方案，可以让不同需求的微服务行为在 Service Mesh 里被当作一个整体看待，极大减轻了开发团队的压力。在 Service Mesh 中，它可以实现应对各种网络状况、提供快速确认机制、在不同认证的网络下保护服务流量、提供组织性策略等功能。这些功能在一定程度上减少了应用程序的代码数量，使服务更快地构建、迁移与发布。

本次新版本的主题在于 enterprise-ready（达到企业应用水平），Istio 团队也就性能和可扩展性做了进一步优化。

Istio 是什么

虽然 Istio 是 Service Mesh 的一种解决方案，但它也可以说是所有解决方案的集大成者。

在 Github 上，如今 Istio 已经摘下超过 16,000 颗星，拥有 335 位贡献者，并得到 Lyft、Google 和 IBM 等大厂的支持，其发展势头不言而喻。

从性能上看，Istio 不仅拥有良好的控制力，可以以 Sidecar 方式进行部署并控制服务间的所有流量，从而控制系统中的所有请求。它还可以与其他类型的 Service Mesh，如 Envoy、Linkerd 一起使用。Envoy 可以做 Istio 的底层，Linkerd、NginMesh 也可以和 Istio 集成。

此前，英国大数据专家 Steven Acreman 曾针对 Istio、Linkerd、Linkerd2 以及 Consul Connect 的性能进行了比较实验。

他的实验结果如下：

• Linkerd 能够在集群内外进行通信但内存开销大，不支持 TCP 请求；

• Linkerd2 数据面与控制面耦合，配置较为简单复杂度低，但功能尚未齐全；

• Consul 权限机制较为完善，配置复杂度低，但文档较少，默认的原生 Sidecar 性能较低；

• Istio 功能完备，文档齐全，完美兼容 Kubernetes 但组件繁多，学习门槛较高。

*注：标注颜色表示有优势，图转自 Steven Acreman 博客

虽然它们各有优缺点，但是根据上表，Istio 的性能相比其他解决方案更为完善。如果用户有用 Kubernetes 构建 Service Mesh 的打算，Istio 可能是不二选择。

Kubernetes 中的 Istio 

从设计上来说，Istio 与平台无关，它可以在许多容器管理平台上部署。但是当 Istio 与 Kubernetes 共同使用时，它的能力将被最大化。

以下是 Istio 的几个简单特性：

• Istio 可以以 YAML ( Istio 有提供 YAML ) 形式快速在 Kubernetes 上部署；

• Istio 的服务注册机制由 Kubernetes 提供，而服务发现由 Istio 中的 Pilot 负责；

• 微服务能够通过 Istio 自动生成遥测平面，无需额外工具就能生成统一的应用指标数据和链路追踪数据；

• Istio 可以为 Kubernetes 的 API 接口和服务间的网络策略提供 RBAC 认证；

• Istio 的认证粒度还能限制到 HTTP 协议的方法和资源路径。

综上所述，在 Kubernetes 上使用 Istio 是非常合适的，这也解释了为什么广大 Kubernetes 开发者对今日发布的 Istio v1.1 给予了极大热情。

新版本的最大的更新在于性能和可扩展性，具体可以概括为以下 4 点：

• 提升了数据平面与控制平面的执行效率：如今 Sidecar 在处理 1000 RPS 时仅需半个 vCPU 的资源提供支撑。另外，单一 Pilot 实例已经能够在配合 1.5 个 vCPU 与 2 GB RAM 的前提下顺利处理 1000 项服务（以及总计 2000 个 Pod）。Sidecar 在半数情况下仅增加 5 ms 延迟，在 99% 的情况下增加 10 ms 延迟（强制执行策略将提高延迟水平）；

• namespace 隔离：用户可以使用 Kubernetes 的 namespace 对边界进行强制控制，进而确保各个团队之间不会相互干扰；

• 改进多集群的功能性与可用性：改进流量控制与策略的默认设置。引入一款名为 Galley 的新组件。Galley 负责验证 YAML 以降低发生配置错误的可能性。另外，Galley 还能够在多集群设置当中发挥作用，从各个 Kubernetes 集群当中收集服务发现信息；

• 支持其它多集群拓扑结构：包括在无需扁平网络的前提下实现单一控制平面与多个同步控制平面。

此外，在安全方面，Istio v1.1 也进行了一系列优化，包括 Vault PKI 的集成、TCP 服务授权、插件凭证保护以及通过 SDS 进行身份配置。Istio 团队还添加了一种创建适配器以影响传入请求的标头和路由的方法，并通过实施新方法、扩展跟踪 ID（包括将跟踪数据发送到的新目标）以及提供禁用混合器支持服务跟踪的选项来改进跟踪。

新版本具体更新，请见：https://istio.io/about/notes/1.1/

Istio 的未来发展

从某种程度上来说，Istio 是 Service Mesh 的代名词，正是  Istio 的出现，Service Mesh 这一概念才真正开始在业界流行，被用于网络配置、安全配置以及服务观察等操作，帮助开发者灵活、简便地实现自动化。从本质上说，Service Mesh 解耦了服务的开发与运维工作。

去年，在 Google 担任 Istio 项目技术项目经理主管的 Jasmine Jaksic 曾发表过对于 Istio 未来的看法，她认为 Istio 作为一个正在开发中的项目，它还有许多亟待解决的问题，如更好地支持混合型环境，更好地提供 API 管理功能。但无论如何，伴随不断增长的接受度及众多贡献者的支持，我们可以相信，Istio 未来的道路将是一片光明。

--

参考文献：

[1]https://istio.io/about/notes/1.1/

[2]https://istio.io/zh/blog/2019/announcing-1.1/

[3]https://kubedex.com/istio-vs-linkerd-vs-linkerd2-vs-consul/

[4]https://devclass.com/2019/03/18/istio-gets-enterprise-ready-pushing-performance-and-scalability/

---

END

推荐阅读：