本文将向你介绍 Istio 服务网格的四种平面部署模式，通过分析它们的优缺点，根据他们的性能、可靠性和安全性给出选择建议。

什么是服务网格？

服务网格是一种基础设施层，通常使用应用代理来实现各种功能。以 Istio 为例，它通过应用代理让用户能够将应用感知的流量管理、强大的可观测性和稳健的安全能力编程到网络中。Istio 确保云原生和分布式系统具有弹性，使现代企业能够在不同平台上维护其工作负载，同时保持连接和受保护。它的功能包括零信任安全、策略管理和访问控制等安全和治理控制，以及金丝雀部署、A/B 测试、负载均衡和故障恢复等网络功能，还能提供对整个网络流量的可观测性。Istio 不受单一集群、网络或运行时的限制，可以将在 Kubernetes 或虚拟机上运行的服务、多云、混合或本地的服务包含在单个网格中。其设计可扩展，并得到广泛生态系统的支持。

服务网格的架构分为控制平面和数据平面，以 Istio 为例，istiod 是它的控制平面，而数据平面有两种部署模式，用户可以选择 sidecar 或 ambient 模式。

实际上服务网格的数据平面的部署模式不止这两种，加上 Istio 支持的 gRPC 无 sidecar 的服务网格，以及 Cilium service mesh，一共有四种部署模式。

数据平面部署模式

下表格从多个维度对服务网格数据平面的部署模式进行了比较。

你可以从下图中更直观地看到这四种模式在成本和安全性方面的比较：

下图说明了服务网格数据平面的不同部署模式中代理的潜在位置。

• Sidecar 模式：代理与应用程序容器位于同一个 Pod 中
• Ambient 模式：L4 代理与应用程序容器位于同一个节点上，L7 代理不一定跟应用程序容器在同一个节点上
• Cilium 模式：L4 和 L7 代理作为一个整体与应用程序容器在同一个节点上
• gRPC 模式：gRPC 框架集成到应用程序中，共同部署在一个容器中

Sidecar 模式：每个服务实例一个 L4 和 L7 的代理

下面展示的是 sidecar 模式中 Application 1 访问同节点上的 Application 2 及跨节点上的 Application 3 的通信路径。

这是最常见的服务网格部署模式，也是 Istio 服务网格起初支持的模式。每个服务实例旁边部署一个代理（如 Envoy），该代理处理进出该服务的所有网络通信，包括 L4 和 L7 网络通信。

• 优点：安全性高，因为每个服务实例都是隔离的，减少了潜在的攻击面。
• 缺点：资源消耗较高，因为每个服务实例都需要单独的代理，增加了基础设施成本。
• 成熟度：Istio Sidecar 模式的成熟度已经达到生产级别，它们经过广泛测试并准备好在实际环境中使用。

Ambient 模式：节点共享 L4 代理，服务账户共享 L7 代理

下面展示的是 ambient 模式中 Application 1 访问同节点上的 Application 2 及跨节点上的 Application 3 的通信路径。

在这种模式下，每个节点上的共享L4代理为同一物理主机上的所有服务实例提供服务，而每个服务账户都有一个专用的L7代理。

• 优点：成本较低，因为多个服务共享同一个代理。
• 缺点：尽管ztunnel（Istio网格中）组件是为安全性设计的，共享代理可能会带来风险。此模型的安全成熟度仍在发展中。
• 成熟度：Istio的Ambient模式目前处于beta阶段，没有大规模的生产级最佳实践，也不支持多集群。

Cilium mesh 模式：共享的 L4 和 L7 代理

下面展示的是 Cilium mesh 模式中 Application 1 访问同节点上的 Application 2 及跨节点上的 Application 3 的通信路径。

这种模式介于完全独立和完全共享之间，每个节点都有一个共享的L7代理。然而，身份和信任模型方面存在已知问题。使用eBPF的Cilium服务网格允许通过内核程序实现无需代理的网络策略。

• 优点：在特定场景下，内核级效率可以降低基础设施成本。
• 缺点：管理更复杂，某些场景可能会导致延迟增加。
• 成熟度：Cilium Mesh通过eBPF直接管理L4流量，并在每个节点上配置Envoy代理以通过CRD（如CiliumEnvoyConfig）控制L7流量。然而，由于身份模型不一致，其安全性令人担忧。该代理是经过定制过的，它具有最少的 Envoy 扩展和 Cilium 策略执行过滤器。因此，该 Cilium mesh 可能无法支持 Envoy 代理的全部功能。

注意：该模式并非 Istio 的数据平面。

gRPC 模式：L4 和 L7 代理集成到应用程序内

在gRPC模式中，没有部署外部代理；而是通过RPC框架将代理功能直接集成到应用程序中，导致对应用程序的显著侵入。服务网格控制平面使用一组称为xDS API的发现API来动态配置应用程序。应用程序中的gRPC客户端库提供对xDS API的广泛支持。利用这种能力，服务网格控制平面可以在服务容器内的这个库中直接编程L4和L7代理功能。

下图展示了在 Istio 的 gRPC 模式中，控制平面如何与应用程序通信。

在这种模式下，当gRPC服务与控制平面通信时，不需要传统的Sidecar代理，而是使用特定的代理进行初始化和与控制平面的通信。此设计减少了资源消耗和部署复杂性，同时仍能实现服务发现、流量管理等功能。

• 优点：高性能，由于代理与应用程序紧密集成，减少了网络跳跃和额外的开销。
• 缺点：高复杂性，需要在应用程序内部实现复杂的网络处理功能，这可能增加开发成本。
• 安全性考虑：这种模式的安全性存在争议。虽然将代理功能集成在应用程序中理论上减少了外部攻击面，但应用程序的多样性和复杂性可能会扩大整体攻击面。因此，在考虑gRPC模式的安全性时，必须仔细分析其具体用例中的安全威胁模型和攻击风险。
• 成熟度：Istio的gRPC模式仍处于实验阶段。

如何选择？

如前所述，选择服务网格数据平面部署模式的决定因素有多个：

• 成熟度
• 企业的安全需求
• 资源限制
• 性能要求
• 网络开销
• 管理复杂性的容忍度

成熟度

在考虑服务网格数据平面部署模式时，成熟度是一个关键因素。每种模式的成熟度都会影响其在生产环境中的可靠性和支持程度：

• Sidecar模式：这是最成熟的服务网格部署模式，广泛应用于生产环境，并得到良好支持。
• Ambient模式：尽管该模式提供了一些成本和性能优势，但它仍处于早期阶段，可能缺乏成熟的最佳实践和广泛的生态系统支持。
• Cilium Mesh模式：作为一个相对较新的选择，它在使用eBPF的场景中提供了独特的技术优势。然而，其安全模型和身份管理的担忧表明，它可能不像其他模式那样成熟或可靠。
• gRPC模式：尽管性能出色，但这种模式的复杂性和侵入性意味着它可能需要更多的定制开发，目前仍处于实验阶段。

安全需求

如果您的业务有较高的安全需求，如金融或医疗行业，那么Sidecar模式可能是最佳选择。这种模式通过确保每个服务实例都有自己独立的代理，从而最大限度地实现服务隔离。对于那些探索较新模式（如Ambient模式）的用户来说，必须了解虽然ztunnel旨在实现安全的本地路由，但该模式的整体安全策略仍在发展中。

资源限制

在资源受限的环境中，为每个服务实例部署一个单独的代理可能不切实际。在这种情况下，可以考虑gRPC模式或Ambient模式。gRPC模式特别适合已经广泛使用gRPC且愿意在应用程序内部处理复杂网络功能的组织。另一方面，Ambient模式通过共享代理来减少资源消耗。

性能要求

对于需要高性能和低延迟的应用程序，gRPC模式提供了最佳性能，因为它消除了传统代理引入的额外网络跳跃。然而，值得注意的是，gRPC模式仍处于实验阶段，可能不支持Istio的所有功能。请根据您的服务网格功能需求进行考虑。

网络开销

每种数据平面模式对网络开销都有不同的影响。Sidecar模式通过本地化路由减少了跨区域流量，但增加了网络跳跃，增加了延迟和计算使用。Ambient模式使用ztunnel进行本地路由，但在waypoint代理下可能会产生跨AZ的成本。Cilium模式将代理放置在与应用程序相同的节点上，可能减少节点间的流量，但可能引入更多的延迟。gRPC模式将RPC框架集成到应用程序中，最小化网络跳跃和开销，适用于高性能、低延迟的需求。

对管理复杂性的容忍度

选择服务网格数据平面模式时，管理复杂性也是一个重要的考虑因素。Sidecar模式和gRPC模式可能需要更复杂的配置和维护，而在某些部署环境中，Ambient模式可能提供更简化的管理体验。Cilium模式由于依赖于eBPF和多个配置点，可能需要更复杂的管理。

结论

选择正确的服务网格数据平面部署模式取决于多个特定因素，包括成熟度、安全性、资源限制、性能和管理复杂性。以下是一个快速指南：

• Sidecar模式：最适合高安全需求，提供最大的隔离性。
• gRPC模式：适用于高性能需求且已在使用gRPC的环境。
• Ambient模式：适合成本效益和较低隔离需求，但安全模型正在演变中。
• Cilium Mesh模式：可能适用于利用eBPF技术的基础设施，但需考虑安全性和管理复杂性。

最佳选择将与您的应用程序需求、安全策略和技术熟悉度相一致。理解每种模式的优势和局限性，以做出平衡收益、风险和成本的明智决策。

参考文献

• 云原生应用的服务网格代理模型