Ambient Mesh模式概述

功能介绍

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

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

设计理念

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

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

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

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的工作负载进行本地通信。

不影响应用程序是使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和其他补丁的攻击面和更新数据平面的频率。

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