进阶!图文详解Istio Ambient Mesh七层服务治理

由于Ambient mesh的工作原理比较复杂，我们在上一篇文章《深度剖析！Istio共享代理新模式Ambient Mesh》中主要剖析了Ambient mesh四层流量治理。因此本文主要集中剖析七层治理部分。建议在阅读本文之前，读者朋友先浏览上一篇文章。

Ambient Mesh七层治理架构

Ambient mesh默认对服务只进行四层治理，用户需要通过定义Gateway资源对象显式的启动七层治理。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
name: productpage
annotations:
istio.io/service-account: bookinfo-productpage
spec:
gatewayClassName: istio-mesh

七层治理架构

如图所示，相比Ambient mesh四层服务治理，七层服务治理增加了新的waypoint组件，这是七层治理的核心组件，本质上waypoint也是通过envoy实现。服务网格七层的治理策略均作用在waypoint上。Sidecar模式Istio七层治理时，流量在客户端和服务端的Sidecar中分别进行七层协议的编解码等操作；而七层流量在Ambient mesh中，七层流量的处理只在一个waypoint中。默认， Pilot通过监听Gateway对象，负责创建单实例的waypoint，那么所有的到Productpage的七层流量均由waypoint代理。生产环境中，单实例waypoint往往不满足高可用、高并发的要求，因此waypoint的扩容策略还需要用户通过第三方软件例如HPA来实现。

Ambient Mesh七层流量治理详解

本例服务部署模型

Sleep发送侧流量处理

(1) sleep访问productpage的流量被同节点的tunnel以TPROXY（透明代理）方式拦截转发到ztunnel(监听127.0.0.1:15001)，使用TPROXY的好处是保留原始的目的地址，ztunnel做转发时必须依赖原始目的地址。这里的拦截方式与前一篇文章中讲的四层流量治理的拦截完全相同，因为在Ambient Mesh中网络层的拦截完全不感知应用层L7协议。

-A PREROUTING -i pistioout -p tcp -j TPROXY --on-port 15001 --on-ip 127.0.0.1 --tproxy-mark 0x400/0xfff

(2) ztunnel通过ztunnel_outbound监听器，监听在15001端口。ztunnel_outbound监听器与Istio Sidecar模式的监听器完全不同，它包含所有本节点上的服务到整个网格其他服务的FilterChain（过滤器链）。

ztunnel_outbound监听器

ztunnel_outbound监听器如何选择合适的FilterChain处理流量的呢？如下图所示，ztunnel_outbound监听器中设置了filter_chain_matcher。其中通过匹配数据包的源IP（10.244.1.4，即sleep容器的地址）、目的IP（10.96.179.71，即produtpage服务的ClusterIP）及目的端口（9080即productpage服务端口号），可以选择名称为"spiffe://cluster.local/ns/default/sa/sleep_to_server_waypoint_proxy_spiffe://cluster.local/ns/default/sa/bookinfo-productpage"的FilterChain来处理Sleep发往Productpage的请求。

FilterChain 匹配器

(3) "spiffe://cluster.local/ns/default/sa/sleep_to_server_waypoint_proxy_spiffe://cluster.local/ns/default/sa/bookinfo-productpage" FilterChain，包含一个TCPProxy过滤器，并且关联到与FilterChain同名的Cluster。即访问请求交由同名的 Cluster处理

FilterChain

(4) "spiffe://cluster.local/ns/default/sa/sleep_to_server_waypoint_proxy_spiffe://cluster.local/ns/default/sa/bookinfo-productpage" Cluster为EDS类型，包含的Endpoint地址为10.244.1.8:15006，即waypoint容器的监听地址。后面我们可以看到waypoint中有监听器监听在15006端口。此Cluster负责将流量进行加密，然后发送到waypoint（10.244.1.8:15006）。

Sleep到Productpage的Cluster

Sleep到Productpage的Endpoint

Waypoint转发

(1) Waypoint首先通过”inbound_CONNECT_terminate”监听器接收Sleep访问Productpage的请求。此监听器上面配置有DownstreamTlsContext，其负责对下游请求进行TLS终止。另外此监听器只有一个FilterChain，包含用于处理HTTP请求的HTTP Connection Manager过滤器。它的核心思想是通过匹配Authority（10.96.179.71:9080，也是原始目的地址）以及CONNECT请求方法进行路由，匹配成功后，选择”inbound-vip|9080|internal|productpage.default.svc.cluster.local” 的 Cluster进行处理。

inbound_CONNECT_terminate监听器

(2) ”inbound-vip|9080|internal|productpage.default.svc.cluster.local” Cluster是一个内部静态类型Cluster，其主要是将流量递交给内部VIP监听器”inbound-vip|9080||productpage.default.svc.cluster.local”，不做其他额外的处理。

Internal productpage cluster

(3) Vip监听器非常重要，一些服务治理策略，比如VirtualService设置的路由策略都在此监听器中加载，这里我们没有配置任何的策略，因此它主要是通过"inbound-vip|9080|http|productpage.default.svc.cluster.local" Cluster进行负载均衡，将将流量转发到Pod监听器处理。

Inbound-vip监听器

Inbound vip cluster

Inbound endpoint

(4) Pod 监听器上会配置服务相关的策略，包括认证、鉴权、Telemetry等策略。这里我们并没有设置任何的流量治理策略，因此Pod监听器比较简单，没有复杂的过滤器。

在本例中，我们启动了两个Productpage服务实例，假设经过"inbound-vip|9080|http|productpage.default.svc.cluster.local" Cluster负载均衡后，流量被转发到10.244.2.8这个Pod监听器。那么流量进而被关联的"inbound-pod|9080||10.244.2.8" Cluster接管。

Inbound-pod监听器

(5) "inbound-pod|9080||10.244.2.8" 是一个静态的Cluster，其主要设置建立CONNECT 相关的metadata，然后将流量转发给” inbound_CONNECT_originate”监听器

Inbound pod cluster

(6) ”inbound_CONNECT_originate”监听器是waypoint处理流程中的最后一个过滤器，它会通过HTTP Connect方法告诉目标ztunnel建立到"%DYNAMIC_METADATA(tunnel:destination)%的隧道，这里CONNECT地址即10.244.2.8:9080。并且通过“set_dst_address”将数据包的目的地址设置为10.244.2.8:15008。

Inbound connect originate监听器

(7) ” inbound_CONNECT_originate” Cluster为ORIGINAL_DST类型，并且设置有TLS Context。因此最后经过TLS加密后，数据包最终被发往10.244.2.8:15008。

Inbound connect originate Cluster

Productpage接收流量处理

Productpage接收测七层的流量处理与四层处理完全相同，请参考https://bbs.huaweicloud.com/blogs/375712

Ambient Mesh七层流量治理小结

七层服务访问数据流

sleep访问productpage的实例中，我们为productpage创建了Gateway，因此Ambient mesh将启动waypoint，代理所有访问productpage的七层流量流量。前面我们深入分析了ztunnel和waypoint中每一个监听器、每一个Cluster的工作原理，看起来可能会很复杂。故在此通过上图进行一个结构性的总结，我们发现在通信的过程中，七层的治理流程明显比四层复杂：

1. 发送侧的路由、iptables：将流量拦截到ztunnel的15001端口

2. 发送侧ztunnel：将productpage请求转发到waypoint

3. Waypoint七层处理：将请求通过四个监听器依次处理，最后发送到接收端

4. 接收侧的路由、iptables：将流量拦截到ztunnel的15008端口

5. 接收ztunnel：virtual_inbound监听器及关联的cluster

Ambient Mesh七层流量治理总结和展望

Istio Sidecar模式下，七层HTTP处理分别在客户端的Sidecar和服务端的Sidecar中进行。而Ambient mesh中，七层HTTP处理仅在waypoint中进行。理论上，七层流量的处理比较复杂，同时比较耗时，所以ambient mesh在这一层面具有一定的优势。但是实际场景中，waypoint的部署位置是不确定的，它可能与客户端、服务端在同一节点上，也有可能与他们任何一方分布在不同的节点，甚至在不同的可用区。所以单纯从时延的角度，很难判断Istio 经典Sidecar模式和Ambient mesh孰优孰劣。

当前Ambient mesh负责waypoint的生命周期，但是只支持了单实例部署，并且没有提供动态扩缩容能力，而实际生产中服务请求往往有明显的峰谷特征，所以Ambient mesh没有应对突发大流量的能力。

Ambient mesh中，每一个服务身份使用独立的waypoint代理自身的访问，这一点在安全性上与Sidecar模式类似，不用担心共享带来的安全性降低。

整体来看，Ambient mesh七层治理架构并没有太大的优势，主要是补充Ambient mesh四层共享代理ztunnel。未来首要解决的就是waypoint本身自动化的问题，必须能够根据服务当前的负载动态扩缩容。

从实现角度来看，waypoint的监听器处理链过长，容易产生重复的计算和处理，并且在开发者角度，过多的xds配置不易维护。因此简化waypoint处理也是长期性能优化的一个主要方向。

Istio Sidecar模式基于Revision的优雅升级目前已经GA，但是Ambient mesh本身由于共享代理的原因，优雅升级功能基本被破坏殆尽。作为微服务的基础设施，Ambient mesh如何支持Revision的优雅升级也将是未来社区关注的头等大事。