![cover](https://img-blog.csdnimg.cn/img_convert/b0162188f723028950a12c5ba2af8116.webp?x-oss-process=image/format,png)
Istio Ambient Mesh七层服务治理图文详解
本文主要集中剖析Ambient mesh七层服务治理相关内容。
摘要:本文主要集中剖析Ambient mesh七层服务治理相关内容。
本文分享自华为云社区《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接收测七层的流量处理与四层处理完全相同,请参考深度剖析!Istio共享代理新模式Ambient Mesh-云社区-华为云
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的优雅升级也将是未来社区关注的头等大事。
更多推荐
所有评论(0)