文档

Ambient Mesh模式概述

更新时间:

本文介绍Ambient Mesh模式的概念及相关功能。

功能介绍

阿里云服务网格ASM从1.18版本开始支持Ambient Mesh模式。该模式下引入了一种新的Sidecarless的数据平面形态,帮助简化应用服务的网格接入,提供一种渐进式采用网格技术的途径,并降低Istio网格用户的基础设施成本。image.png

ASM Ambient Mesh支持Sidecar和Sidecarless两种形态的数据平面架构。您可以根据应用程序的需求选择其中之一或两者融合使用。在ASM 1.18版本中,Sidecar代理已支持HBONE(基于HTTP的覆盖网络环境),因此它们可以通过零信任隧道ztunnel提供安全覆盖层、通过Waypoint代理提供7层处理能力,支持Sidecarless模式下的应用程序相互操作。

设计理念

将数据平面分层:4层用于基础处理,特点是低资源、高效率;7层用于高级流量处理,特点是功能丰富,但需要更多的资源。您可以根据所需功能的范围,以渐进增量的方式使用服务网格技术。

层级

主要功能

4层

  • 流量管理:TCP路由

  • 安全:面向4层的简单授权策略、双向TLS

  • 可观测:TCP监控指标及日志

7层

  • 流量管理:HTTP路由、负载均衡、熔断、限流、故障容错、重试、超时等

  • 安全:面向7层的精细化授权策略

  • 可观测:HTTP监控指标、访问日志、链路追踪

数据面L4与L7代理的解耦模式下,一方面,将L4 Proxy能力下移到CNI组件中,L4 Proxy组件以DaemonSet的形式运行,分别运行在每个节点上。这意味着它是为一个节点上运行的所有Pod提供服务的共享基础组件。

另一方面,L7代理不再以Sidecar模式存在,而是解耦出来,称为Waypoint Proxy,它是为每一个Service Account创建的7层代理Pod。

概述1.png

4层和7层代理的配置仍然保持通过Service Mesh控制面组件来进行下发管理。通过这种解耦模式,实现了Service Mesh数据平面与应用程序之间的进一步解耦分离。

在Istio的具体实现中,可以分为以下3个部分:

  • Waypoint代理:

    • L7组件完全独立于应用程序运行,安全性更高。

    • 每个身份(Kubernetes中的服务账户)都有自己专用的L7代理(Waypoint代理),避免多租户L7代理模式引入的复杂度与不稳定性。

    • 通过K8s Gateway CRD定义触发启用。

  • ztunnel:将L4处理下沉到CNI级别,来自工作负载的流量被重定向到ztunnel,然后ztunnel识别工作负载并选择正确的证书进行处理。

  • 与Sidecar模式兼容:Sidecar模式仍然是网格的一等公民,Waypoint代理可以与部署了Sidecar的工作负载进行本地通信。

概述2.png

不影响应用程序是使Ambient Mesh比传统的Sidecar模式具备更少侵入性的原因之一。与采用Sidecar模式时必须将Sidecar代理注入到每个应用程序部署中相比,Ambient模式下无需以任何方式重新部署或修改现有应用程序。通过不重新部署和直接修改应用程序,可以有效地降低落地风险并简化采用Mesh的落地曲线。

Ambient Mesh的设计是非侵入式的,并且仅对存在特定标记的命名空间并使现有应用程序成为Ambient Mesh的一部分,可以逐步采用。一旦应用程序成为Ambient Mesh的一部分,它立即获得mTLS和L4可观察性功能。

Ambient模式下的路由

在Ambient Mesh模式下,工作负载可以分为以下3类:

  • 未拦截:这是一个没有启用任何Mesh特性的标准Pod。

  • 已拦截:这是一个通过ztunnel拦截流量的Pod。可以通过在命名空间上设置istio.io/dataplane-mode=ambient标签来捕获Pod。

  • Waypoint启用:这是一个已拦截且部署了Waypoint代理的Pod。默认情况下,Waypoint代理将应用于同一命名空间中的所有Pod。还可以通过在Gateway上设置istio.io/for-service-account注释,将其设置为仅适用于特定的服务账户。如果同时存在命名空间Waypoint代理和服务账户Waypoint代理,则服务账户Waypoint代理的优先级更高。

Ztunnel路由

  • 出站

    当一个被拦截的Pod发起出站请求时,它将被透明地重定向到ztunnel,ztunnel将确定请求的转发位置和方式。一般情况下,流量路由的行为与Kubernetes默认的流量路由相同。对一个Service的请求将被发送到该Service内的一个端点,而直接对Pod IP的请求将直接发送到该IP。根据目标的能力,会发生不同的行为。如果目标也被拦截,或者具有Istio代理能力(例如注入了Sidecar代理或网关),请求将升级为加密的HBONE隧道。如果目标有一个Waypoint代理,除了升级为HBONE外,请求将被转发到该Waypoint代理。

    需要注意的是,在请求一个Service时,会选择一个特定的端点来确定是否有Waypoint代理。但是,如果有Waypoint代理,请求将被发送到Service的目标目的地,而不是选定的端点。这样可以使Waypoint代理将面向服务的策略应用于流量。在Service同时具有启用Waypoint和未启用Waypoint的端点的罕见情况下,一些请求将被发送到Waypoint,而对同一服务的其他请求则不会。

  • 入站

    当一个被拦截的Pod接收到入站请求时,它将被透明地重定向到ztunnel。当ztunnel接收到请求时,它将应用授权策略,并只有在请求符合策略时才转发请求。一个Pod可以接收HBONE流量或明文流量。默认情况下,ztunnel将接受这两种流量。因为在评估授权策略时,明文请求没有对等身份,您可以设置一个策略要求一个身份(任意身份或特定身份),以阻止所有明文流量。

    当目标启用了Waypoint代理时,所有请求必须经过Waypoint代理来执行策略。ztunnel将确保这一点,但存在一个特殊情况:良好行为的HBONE客户端(例如另一个ztunnel或Istio Sidecar代理)会知道将请求发送到waypoint,但其他客户端(例如网格之外的工作负载)可能对waypoint代理一无所知,直接发送请求。当发送这些直接调用时,ztunnel会将请求绕圈(hairpin)到它的waypoint,以确保策略得到正确执行。

Waypoint路由

Waypoint代理只接收HBONE请求。在接收到请求后,Waypoint代理将确保请求的目标是其管理的Pod或包含其管理的Pod的Service。

对于任何类型的请求,在转发之前,Waypoint代理将执行策略(例如授权策略、Wasm插件、遥测等)。

对于直接请求到Pod的情况,策略应用后,请求将直接转发。

对于针对Service的请求,Waypoint代理还将应用路由和负载均衡。默认情况下,Service将简单地路由到自身,并在其端点间进行负载均衡。您可以通过为该Service设置路由来覆盖默认行为。

与Sidecar模式的差异点

  • 4层与7层处理的解耦,引入基于Rust的ztunnel作为基础的4层处理模块,适合做高性能、低利用率的网络代理能力。

  • Waypoint代理面向目标服务进行定义,仅需包含非常有限的动态集群、端点和路由相关的详细信息,而无需将所有潜在连接到其运行的Kubernetes集群中的任何服务的详细信息都包含内。这有效地消除了对Waypoint代理支持Sidecar资源的需求,也避免您手动配置Sidecar资源。

Ambient Sidecarless模式的优势

  • 网格代理与应用程序解耦,独立运行,当代理更新或重启时,不需要对应用程序进行重启。

  • 扩大了对应用程序的支持,包括支持Kubernetes Jobs等。

  • 消除了Sidecar模式下对应用程序的要求,包括服务器发送优先协议等。

  • 更好地逐步采用网格技术的接入,例如从安全覆盖层开始,使用加密身份的mTLS、简单的第4层授权策略和可观测功能。

  • 在没有任何L7处理的情况下,安全覆盖层显著地减少了CVE和其他补丁的攻击面和更新数据平面的频率。

  • 独立于工作负载扩展服务网格数据平面,从而降低基础设施的成本。

  • 本页导读 (1)
文档反馈