Istio Ambient Mesh七层服务治理图文详解( 二 ) _生活百科

文章插图
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没有应对突发大流量的能力。