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

举报
云容器大未来 发表于 2022/11/02 21:39:38 2022/11/02
【摘要】 由于Ambient mesh的工作原理比较复杂,我们在上一篇文章《深度剖析!Istio共享代理新模式Ambient Mesh》中主要剖析了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过滤器它的核心思想是通过匹配Authority10.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.localCluster是一个内部静态类型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” ClusterORIGINAL_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. 发送侧ztunnelproductpage请求转发到waypoint

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

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

5. 接收ztunnelvirtual_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的优雅升级也将是未来社区关注的头等大事


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200