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

istio,ambient,mesh,七层,服务,治理,图文,详解 · 浏览次数 : 544

小编点评

**华为云新鲜技术七层流量治理总结** **1. 发送侧路由、iptables:将流量拦截到ztunnel的15001端口** **2. 发送侧ztunnel:将productpage请求转发到waypoint3** **3. Waypoint七层处理:将请求通过四个监听器依次处理,最后发送到接收端4** **4. 接收侧的路由、iptables:将流量拦截到ztunnel的15008端口** **5. 接收ztunnel:virtual_inbound监听器及关联的clusterAmbient Mesh七层流量治理总结和展望Istio Sidecar模式下,七层HTTP处理分别在客户端的Sidecar和服务端的Sidecar中进行** **6. 接收侧的路由、iptables:将流量拦截到ztunnel的15008端口** **7. 接收ztunnel:virtual_inbound监听器及关联的clusterAmbient Mesh七层流量治理总结和展望Istio Sidecar模式下,七层HTTP处理仅在waypoint中进行**

正文

摘要:本文主要集中剖析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接收测七层的流量处理与四层处理完全相同,请参考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的优雅升级也将是未来社区关注的头等大事。

 

点击关注,第一时间了解华为云新鲜技术~

与Istio Ambient Mesh七层服务治理图文详解相似的内容:

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

摘要:本文主要集中剖析Ambient mesh七层服务治理相关内容。 本文分享自华为云社区《Istio Ambient Mesh七层服务治理图文详解》,作者:华为云云原生团队。 由于Ambient mesh的工作原理比较复杂,我们在上一篇文章《深度剖析!Istio共享代理新模式Ambient Mes

Istio数据面新模式:Ambient Mesh技术解析

摘要:Ambient Mesh以一种更符合大规模落地要求的形态出现,克服了大多数Sidecar模式的固有缺陷,让用户无需再感知网格相关组件,真正将网格下沉为基础设施。 本文分享自华为云社区《华为云云原生团队:Istio数据面新模式 Ambient Mesh技术解析》,作者: 云容器大未来。 如果说在

Ambient Mesh:Istio 数据面新模式

摘要:基于Istio对于Kubernetes生态的完美补充,随着Kubernetes的大规模普及,Istio 数据面新模式 —Ambient MeshIstio也实现了对用户心智以及市场的快速抢占。 本文分享自华为云社区《Istio 数据面新模式 —Ambient Mesh》,作者:创原会。 如果说

istio sidecar 工作方式

istio 是什么 Istio 是一个开放源代码的服务网格,它为基于微服务的应用程序提供了一种统一的方式来连接、保护、监控和管理服务。Istio 主要解决的是在微服务架构中的服务间通信的复杂性问题,它通过提供服务间的负载均衡、服务到服务的认证、监控以及服务的弹性(例如重试、熔断等)来实现。 side

Istio 升级后踩的坑

背景 前段时间我们将 istio 版本升级到 1.12 后导致现有的应用监控有部分数据丢失(页面上显示不出来)。 一个是应用基础信息丢失。 再一个是应用 JVM 数据丢失。 接口维度的监控数据丢失。 修复 基础信息 首先是第一个基础信息丢失的问题,页面上其实显示的是我们的一个聚合指标istio_re

《 Istio 权威指南 》新著重磅发行!华为云云原生团队匠心力作

摘要:由 Istio社区指导委员会成员和华为云云原生团队联合编著的云原生服务网格书籍《 Istio 权威指南》重磅上市 本文分享自华为云社区《《 Istio 权威指南 》新著重磅发行!华为云云原生团队匠心力作》,作者: 云容器大未来 。 由 Istio 社区指导委员会成员和华为云云原生团队联合编著的

[转帖]什么是 istio

https://cizixs.com/2018/08/26/what-is-istio/ 如果你比较关注新兴技术的话,那么很可能在不同的地方听说过 istio,并且知道它和 service mesh 有着牵扯。这篇文章是我之前在公司内部做过的分享,可以作为了解 istio 的入门介绍,了解什么是 i

基于 Istio 的灰度发布架构方案实践之路

灰度发布,是指能够平滑过渡的一种发布方式。尤其是对于toB业务和SAAS类平台,很多情况需要根据租户或用户维度进行灰度控制,实现业务上的A/Best功能。尽管几经迭代,但仍存在系统入侵性强、新版本接口异常等问题。因此,探索了一条基于Istio的服务流量治理方案下的灵活可配置的灰度发布方案。