为什么选择 Istio?

Istio 在 2017 年推出时率先提出了基于 sidecar 的服务网格的概念。该项目从一开始就包含了定义服务网格的功能,包括用于零信任网络的基于标准的双向 TLS、智能流量路由以及通过指标、日志和跟踪进行的可观察性。

从那时起,该项目推动了网格领域的进步,包括 多集群和多网络拓扑通过 WebAssembly 进行扩展Kubernetes 网关 API 的开发,以及通过 ambient 模式 将网格基础设施从应用程序开发人员手中移开。

以下是一些我们认为您应该将 Istio 作为服务网格的原因。

简单而强大

Kubernetes 拥有数百个功能和数十个 API,但您只需一条命令即可开始使用它。我们构建 Istio 的方式也是如此。渐进式披露意味着您可以使用一小部分 API,只有在需要时才使用更强大的功能。其他“简单”的服务网格花费了数年时间才赶上 Istio 第一天就拥有的功能集。

有备无患胜过无备之需!

Envoy 代理

从一开始,Istio 就由 Envoy 代理提供支持,Envoy 是一款由 Lyft 最初构建的高性能服务代理。Istio 是第一个采用 Envoy 的项目,并且 Istio 团队是首批外部贡献者。Envoy 后来成为 为 Google Cloud 提供支持的负载均衡器,以及几乎所有其他服务网格平台的代理。

Istio 继承了 Envoy 的所有强大功能和灵活性,包括使用 WebAssembly 的世界一流的可扩展性,该可扩展性是 由 Istio 团队在 Envoy 中开发的

社区

Istio 是一个真正的社区项目。2023 年,有 10 家公司对 Istio 做出了 1000 多次贡献,没有一家公司的贡献超过 25%。(在此处查看数据)。

没有其他服务网格项目像 Istio 一样拥有如此广泛的行业支持。

软件包

我们向所有人提供稳定的二进制版本,每个版本都提供,并承诺继续这样做。我们为 最新版本和一些先前版本 发布免费且定期的安全补丁。我们的许多供应商将支持旧版本,但我们认为,参与供应商不应成为在稳定的开源项目中保持安全性的必要条件。

考虑的替代方案

一份好的设计文档包含一个关于已考虑但最终被拒绝的备选方案的部分。

为什么不“使用 eBPF”?

我们确实如此——在适当的情况下!Istio 可以配置为使用 eBPF 将流量从 Pod 路由到代理。这显示出比使用iptables略微提高的性能。

为什么不将其用于所有操作?没有人这样做,因为实际上没有人能够做到。

eBPF 是在 Linux 内核中运行的虚拟机。它专为保证在有限的计算环境中完成的功能而设计,以避免破坏内核行为,例如执行简单 L3 流量路由或应用程序可观察性的功能。它并非为 Envoy 中发现的长时间运行或复杂功能而设计:这就是操作系统具有 用户空间 的原因!eBPF 维护人员推测它最终可以扩展到支持运行像 Envoy 这样复杂的程序,但这只是一个科学项目,不太可能具有现实世界的实用性。

其他声称“使用 eBPF”的网格实际上对大部分功能使用每个节点的 Envoy 代理或其他用户空间工具。

为什么不使用每个节点代理?

Envoy 本身并非多租户。因此,我们对在共享实例中混合来自多个不受约束的租户的复杂 L7 流量处理规则存在重大的安全性和稳定性问题。由于 Kubernetes 默认情况下可以将来自任何命名空间的 Pod 调度到任何节点,因此节点不是合适的租户边界。预算和成本归因也是主要问题,因为 L7 处理的成本远高于 L4。

在环境模式下,我们将 ztunnel 代理严格限制为 L4 处理——就像 Linux 内核一样。这大大减少了漏洞攻击面,并使我们能够安全地操作共享组件。然后将流量转发到每个命名空间运行的 Envoy 代理,这样就不会有任何 Envoy 代理是多租户的。

我有一个 CNI。为什么还需要 Istio?

如今,一些 CNI 插件开始提供类似服务网格的功能作为附加组件,该组件位于其自己的 CNI 实现之上。例如,它们可能会实现自己的节点或 Pod 之间流量的加密方案、工作负载身份或通过将流量重定向到 L7 代理来支持一定程度的传输级策略。这些服务网格附加组件是非标准的,因此只能在其提供的 CNI 之上运行。它们还提供不同的功能集。例如,构建在 Wireguard 之上的解决方案无法实现 FIPS 合规性。

因此,Istio 实现了其零信任隧道 (ztunnel) 组件,该组件使用经过验证的行业标准加密协议透明高效地提供此功能。 了解有关 ztunnel 的更多信息

Istio 旨在成为一个服务网格,提供一致、高度安全、高效且符合标准的服务网格实现,提供 强大的 L7 策略集平台无关的工作负载身份,使用 行业验证的 mTLS 协议——在任何环境中,使用任何 CNI,甚至跨具有不同 CNI 的集群。

此信息是否有用?
您是否有任何改进建议?

感谢您的反馈!