Istio Ambient Mesh 七层服务治理图文详解
本文分享自华为云社区《Istio Ambient Mesh七层服务治理图文详解》，作者：华为云云原生团队。
由于 Ambient mesh 的工作原理比较复杂，我们在上一篇文章《深度剖析！Istio共享代理新模式Ambient Mesh》中主要剖析了 Ambient mesh 四层流量治理。因此本文主要集中剖析七层治理部分。建议在阅读本文之前，读者朋友先浏览上一篇文章。
Ambient Mesh 七层治理架构
Ambient mesh 默认对服务只进行四层治理，用户需要通过定义 Gateway 资源对象显式的启动七层治理。
七层治理架构
如图所示，相比 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 协议。
(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 的优雅升级也将是未来社区关注的头等大事。
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/384902edfe74e7e2400387cca】。文章转载请联系作者。
提供全面深入的云计算技术干货 2020-07-14 加入
华为云开发者社区，提供全面深入的云计算前景分析、丰富的技术干货、程序样例，分享华为云前沿资讯动态，方便开发者快速成长与发展，欢迎提问、互动，多方位了解云计算！ 传送门：https://bbs.huaweicloud.com/
评论