本文将向你介绍 Istio 服务网格的四种平面部署模式,通过分析它们的优缺点,根据他们的性能、可靠性和安全性给出选择建议。
服务网格是一种基础设施层,通常使用应用代理来实现各种功能。以 Istio 为例,它通过应用代理让用户能够将应用感知的流量管理、强大的可观测性和稳健的安全能力编程到网络中。Istio 确保云原生和分布式系统具有弹性,使现代企业能够在不同平台上维护其工作负载,同时保持连接和受保护。它的功能包括零信任安全、策略管理和访问控制等安全和治理控制,以及金丝雀部署、A/B 测试、负载均衡和故障恢复等网络功能,还能提供对整个网络流量的可观测性。Istio 不受单一集群、网络或运行时的限制,可以将在 Kubernetes 或虚拟机上运行的服务、多云、混合或本地的服务包含在单个网格中。其设计可扩展,并得到广泛生态系统的支持。
服务网格的架构分为控制平面和数据平面,以 Istio 为例,istiod
是它的控制平面,而数据平面有两种部署模式,用户可以选择 sidecar 或 ambient 模式。
实际上服务网格的数据平面的部署模式不止这两种,加上 Istio 支持的 gRPC 无 sidecar 的服务网格,以及 Cilium service mesh,一共有四种部署模式。
下表格从多个维度对服务网格数据平面的部署模式进行了比较。
数据平面模式 | 平台安全性 威胁评估、风险 | 资源效率 – 基础设施/资源消耗等 | 可管理性 – 升级、漏洞等 | 性能 – 延迟等 |
---|---|---|---|---|
Sidecar模式:每个服务实例的L4和L7代理 | 高安全性,因为每个服务实例都有独立的代理,减少了攻击面。风险管理取决于控制平面配置。 | 较高的资源消耗,因为每个实例需要独立的代理。 | 需要集中管理和配置,升级相对复杂,但可以通过控制平面简化。 | 请求需要通过代理转发,可能增加延迟。 |
Ambient模式:共享L4 – L7每个服务模型 | 通过ztunnel进行本地路由设计的安全性。然而,共享代理可能会带来风险,其整体安全成熟度仍在发展中。 | 效率较高,因为多个服务共享相同的代理。 | 管理相对简单,但可能因共享代理而面临漏洞。 | 本地路由性能良好,但在waypoint代理下可能会产生跨AZ的成本。 |
Cilium Mesh模式:共享L4和L7模型 | 中等安全性,专注于eBPF和细粒度访问控制。然而,身份和信任模型方面存在已知问题。 | 内核级处理提高效率,减少基础设施开销。 | 管理更复杂,需要处理多个服务的配置。 | 性能可变;某些场景可能会引入显著的延迟。 |
gRPC模式:L4和L7集成在应用模型中 | 虽然gRPC将代理功能集成在应用程序中,理论上减少了攻击面,但应用程序的复杂性和多样性实际上可能扩大它。gRPC模式的安全性依赖于具体的用例,需要对潜在威胁和攻击面进行仔细评估。 | 更高的效率,因为代理在与应用相同的进程中实现。 | 管理复杂,需要定期更新和维护应用层代理。 | 性能优越,延迟低,适合实时应用。 |
你可以从下图中更直观地看到这四种模式在成本和安全性方面的比较:
下图说明了服务网格数据平面的不同部署模式中代理的潜在位置。
下面展示的是 sidecar 模式中 Application 1 访问同节点上的 Application 2 及跨节点上的 Application 3 的通信路径。
这是最常见的服务网格部署模式,也是 Istio 服务网格起初支持的模式。每个服务实例旁边部署一个代理(如 Envoy),该代理处理进出该服务的所有网络通信,包括 L4 和 L7 网络通信。
下面展示的是 ambient 模式中 Application 1 访问同节点上的 Application 2 及跨节点上的 Application 3 的通信路径。
在这种模式下,每个节点上的共享L4代理为同一物理主机上的所有服务实例提供服务,而每个服务账户都有一个专用的L7代理。
下面展示的是 Cilium mesh 模式中 Application 1 访问同节点上的 Application 2 及跨节点上的 Application 3 的通信路径。
这种模式介于完全独立和完全共享之间,每个节点都有一个共享的L7代理。然而,身份和信任模型方面存在已知问题。使用eBPF的Cilium服务网格允许通过内核程序实现无需代理的网络策略。
注意:该模式并非 Istio 的数据平面。
在gRPC模式中,没有部署外部代理;而是通过RPC框架将代理功能直接集成到应用程序中,导致对应用程序的显著侵入。服务网格控制平面使用一组称为xDS API的发现API来动态配置应用程序。应用程序中的gRPC客户端库提供对xDS API的广泛支持。利用这种能力,服务网格控制平面可以在服务容器内的这个库中直接编程L4和L7代理功能。
下图展示了在 Istio 的 gRPC 模式中,控制平面如何与应用程序通信。
在这种模式下,当gRPC服务与控制平面通信时,不需要传统的Sidecar代理,而是使用特定的代理进行初始化和与控制平面的通信。此设计减少了资源消耗和部署复杂性,同时仍能实现服务发现、流量管理等功能。
如前所述,选择服务网格数据平面部署模式的决定因素有多个:
在考虑服务网格数据平面部署模式时,成熟度是一个关键因素。每种模式的成熟度都会影响其在生产环境中的可靠性和支持程度:
如果您的业务有较高的安全需求,如金融或医疗行业,那么Sidecar模式可能是最佳选择。这种模式通过确保每个服务实例都有自己独立的代理,从而最大限度地实现服务隔离。对于那些探索较新模式(如Ambient模式)的用户来说,必须了解虽然ztunnel旨在实现安全的本地路由,但该模式的整体安全策略仍在发展中。
在资源受限的环境中,为每个服务实例部署一个单独的代理可能不切实际。在这种情况下,可以考虑gRPC模式或Ambient模式。gRPC模式特别适合已经广泛使用gRPC且愿意在应用程序内部处理复杂网络功能的组织。另一方面,Ambient模式通过共享代理来减少资源消耗。
对于需要高性能和低延迟的应用程序,gRPC模式提供了最佳性能,因为它消除了传统代理引入的额外网络跳跃。然而,值得注意的是,gRPC模式仍处于实验阶段,可能不支持Istio的所有功能。请根据您的服务网格功能需求进行考虑。
每种数据平面模式对网络开销都有不同的影响。Sidecar模式通过本地化路由减少了跨区域流量,但增加了网络跳跃,增加了延迟和计算使用。Ambient模式使用ztunnel进行本地路由,但在waypoint代理下可能会产生跨AZ的成本。Cilium模式将代理放置在与应用程序相同的节点上,可能减少节点间的流量,但可能引入更多的延迟。gRPC模式将RPC框架集成到应用程序中,最小化网络跳跃和开销,适用于高性能、低延迟的需求。
选择服务网格数据平面模式时,管理复杂性也是一个重要的考虑因素。Sidecar模式和gRPC模式可能需要更复杂的配置和维护,而在某些部署环境中,Ambient模式可能提供更简化的管理体验。Cilium模式由于依赖于eBPF和多个配置点,可能需要更复杂的管理。
选择正确的服务网格数据平面部署模式取决于多个特定因素,包括成熟度、安全性、资源限制、性能和管理复杂性。以下是一个快速指南:
最佳选择将与您的应用程序需求、安全策略和技术熟悉度相一致。理解每种模式的优势和局限性,以做出平衡收益、风险和成本的明智决策。
最后更新于 2024/10/08