两全其美：Sidecarless 与 Sidecar 模式融合的服务网格新形态
作者：史泽寰、尹航
Istio 社区与 2022 年 9 月发布了一种名为 Ambient 的新架构，由于其从架构上将 Sidecar 转变为 4 层和 7 层代理，故而这种模式也被称为 Sidecarless 模式。阿里云服务网格 ASM 是业内首个支持 Ambient 模式的托管式服务网格。
本文基于 2023 云栖大会上关于阿里云服务网格 ASM 产品技术最新进展分享的实录，来自阿里云云原生产品线服务网格团队的史泽寰、尹航同学将用 4 个部分，为读者介绍 ASM 如何落地这种 Sidecarless 和 Sidecar 模式融合的服务网格新形态，以及服务网格的 Serverless 化。
服务网格架构的演进
随着服务网格在云原生技术体系下越来越流行，越来越多的企业技术团队在生产环境使用服务网格，相信有很多朋友已经了解过服务网格，为了方便刚开始接触服务网格的同学更顺畅地理解后续内容，我们先来对服务网格经典的 Sidecar 模式做一个介绍。
经典服务网格架构根据组件的职责被划分为控制平面和数据平面，控制平面扮演服务网格的大管家，为数据平面组件根据需求提供不同的配置，数据平面作为执行者，它可以根据控制平面下发的配置对流量进行操纵，是服务网格能力真正的执行者。
为了实现流量路由、负载均衡、故障注入、请求响应操纵或是认证鉴权、零信任网络等等服务网格能力，服务网格的注入器（Injector）会向应用 Pod 注入一个专门用于执行服务网格能力的容器，它与应用在同一个 Pod 内，共享网络命名空间，这个容器就是服务网格的 Sidecar。
由于 Sidecar 与应用容器共享网络命名空间，可以通过 iptables 规则方便地将应用的流量拦截到位于该容器内的网格代理进程，这便是经典的 Sidecar 架构。
ASM 将控制平面与数据平面解耦，托管化部署，相比于 Istio，ASM 具备一些显著的优势。首先，ASM 具备完善的生命周期管理能力， 在服务网格运维实践中，由于服务网格配置复杂，社区迭代快速，往往安装、升级服务网格都会存在一些挑战，借助 ASM 的生命周期管理能力，用户可以一键创建、删除、升级服务网格实例而完全不需要考虑配置问题或兼容适配问题。
其次，ASM 提供了屏蔽错误配置和诊断的能力， 我们观察到一些客户在使用服务网格的过程中，配置错误导致结果不符合预期是比较常见的问题，ASM 将这些问题转化成为检查项、诊断项，尽早对错误的配置进行拦截和告警，帮助服务网格运维人员及时发现和解决问题。服务网格作为云原生应用的网络基础设施，可以帮助应用与可观测平台进行对接，为此，ASM 提供了一键快速对接多种云服务的能力，帮助用户快速打通云原生生态体系。
最后，ASM 提供了企业级的多集群模式支持， 通过 ASM 用户可以快速实现多数据面集群的网格化。
ASM 目前将部分控制平面组件 Serverless 化，Serverless 化的组件可以实现自动化弹性扩容，按需使用。基于 Serverless 底座的能力，实现更高的调度效率和启动速度优化，通过镜像缓存，显著降低就绪时间和启动时间。
新型的数据平面模式
Sidecar 模式是非常直观且有效的，但它仍然存在一些缺点：
1）Sidecar 的注入对工作负载存在侵入性，注入或取消注入需要重启工作负载，调整 Sidecar 的配置（例如资源）也可能需要重启工作负载，Sidecar 和工作负载是强绑定的。
2）资源利用率不够理想，为了应对最坏情况，每个 Sidecar 都需要预留一部分资源，集群规模越大，闲置的资源越多。
3）流量捕获、协议识别等等 7 层处理的计算成本高，但并非所有请求都是 HTTP 协议，或是需要经过 Sidecar 处理的。
基于以上原因，我们需要一种侵入性更小，使用成本更低的方式， 让服务网格适用于更多场景。于是，2022 年 9 月，Istio 社区推出了 Sidecarless 的 Ambient 模式， 该模式将 Sidecar 的功能拆分至 4 层和 7 层代理，且 4 层代理和 7 层代理的部署均与工作负载分离，很好地弥补了 Sidecar 模式在一些场景下的缺点。ASM 则是业界首个支持 Ambient 模式的托管式服务网格。
在 Ambient 模式下，4 层代理主要专注于传输层的可观测、路由以及通信加密，7层代理则基于 7 层协议在流量管理、安全、可观测维度进行更复杂的行为处理。用户可以根据实际业务需求，渐进式地选择是否为应用启用代理，启用哪一层的代理。
我们将数据面的 L4 代理称之为 Ztunnel，它是一个 L4 处理层，L4 处理层将负责应用的所有 4 层通信的转发，借助 ztunnel 的能力，使得应用在加入网格后立即获得零信任安全能力，包括 MTLS，身份验证和授权策略。ztunnel 以 DaemonSet 模式部署后，利用 CNI 在节点上配置流量拦截规则，将网格内 Pod 的流量拦截至 ztunnel 实例，ztunnel 将流量经过 MTLS 加密后传输，对端 ztunnel 将流量解密，然后转发至应用。借助以上路径，ztunnel 还可以收集 TCP 监控指标，访问日志等。
我们将 7 层代理称为 Waypoint 代理，Waypoint 代理与经典架构中的 Sidecar 一样，是基于 Envoy 的代理，用于在 Ambient Mesh 模式中实现更高级的，基于 7 层协议的能力。例如，它可以基于请求标头和凭据来应用服务网格的高级策略，诸如熔断、流量整形，流量分割，重试，故障注入，基于角色的访问控制授权策略等等。相比于 Ztunnel 代理基于节点级部署，Waypoint 代理则是以服务级别部署，用户可以针对性地为某个服务启用或关闭 7 层代理，或是任意伸缩部署规模，按需部署，提高集群中资源的利用率。
在了解 L4 和 L7 代理的具体能力之后，我们来看一下 L4、L7 解耦的 Ambient 模式下的网络拓扑：
接下来我们来看看 Ambient 模式下的流量路径是怎样的，首先从 L4 代理开始：
-
Ambient 模式下的应用 Pod 启动时，CNI 插件会将其 IP 地址写入到节点网络命名空间下的 ipset 中。
-
发起请求时，流量数据包通过 Pod 的 veth pair 接口到达节点网络命名空间，来自 ipset 中地址的数据包将被节点上 iptables 规则捕获并进行处理。
-
Iptables 规则将数据包被标记为 0x100。
-
节点上的策略路由规则指定任何标记为 0x100 的数据包都要通过 istio 出向网络接口定向到目标 192.168.127.2。
-
ztunnel 代理 Pod 中的透明代理 iptables 规则将来自 pistioout 的数据包送入 ztunnel 出站端口 15001。
-
ztunnel 处理数据包并将其转发至目标服务（httpbin）的 IP 地址。该地址在节点 B 上时 httpbin 的 veth 设备地址，数据包因此被路由至节点 B。
-
数据包到达节点 B 后，入站流量的规则确保数据包被路由到 istioin 接口。
-
数据包通过 istioin 和 pistioin 组成的隧道使数据包进入 ztunnel pod。
-
Ztunnel Pod 中的 iptables 规则捕获来自 pistioin 的数据包，并根据标记将它们定向到端口 15008。
-
ztunnel pod 处理数据包并将其发送至目标 pod。
当 4 层代理转发 Outbound 数据时，若目标应用启用了 7 层代理，4 层代理会将流量通过 HBONE 隧道转发至目标应用的 7 层代理，流量将通过监听在 15008 端口的 connect terminate Listener 进入 7 层代理，这个 Listener 上通过特定的 Filter 处理，将 HBONE 流量解包并完成身份认证后，将流量送入 main internal 内部监听器进行后续处理。在 main listener 上，根据 Service IP+Port 对流量进行匹配，并执行 7 层流量策略，确定目标 Cluster。最后，流量进入名为 connect_originate 的 internal Listener，该 Listener 使用 HBONE 隧道继续将流量转发至上游目标。
对于 Ambient Mesh 流量路径有兴趣的读者也可以参考笔者的另一篇文章，在这篇文章中对 Ambient 模式下的流量路径做了更深入细致的剖析。
Sidecarless 与Sidecar 模式融合的新形态
在新的架构中，Sidecar 模式与 Sidecarless 模式并不冲突，用户可以混合使用两种模式混合部署，借助这个特性，根据需求渐进式完成切换成为可能。ASM 的托管 Ambient 模式在特定场景下最多可以减少 60% 资源开销、减少 50% 运维工作以及降低 40% 的请求时延。
ASM 通过统一的控制平面 API，为数据平面提供配置管理平台，为融合形态中 Sidecar 模式下的 Sidecar，Sidecarless 模式下的 4 层代理、7 层代理，甚至托管的代理，按需下发不同的配置。
由于七层代理承载了更丰富的服务网格能力，在生产实践中，七层代理更有可能需要跟随业务应用的扩缩容同时进行扩缩容。基于新架构下七层代理部署的灵活性，ASM 提供了托管的 7 层代理，将七层代理以 Serverless 形态部署，屏蔽 7 层代理的运维复杂度，用户无需为 7 层代理提前进行容量规划，也不需要承担 7 层代理的任何运维工作，根据业务需要，随时可以对 7 层代理进行部署、回收以及一键扩缩容。
下面我们来看看托管 7 层代理的技术架构，用户可以通过 K8s 标准的 Gateway API 声明 7 层代理，位于 ASM 托管侧的 Waypoint Proxy Controller 将会 Watch Gateway API，当 Gateway CR 创建、变更后，Waypoint Proxy Controller 根据 Gateway API 的 spec 对 Waypoint Proxy 工作负载进行生命周期管理。用户可以通过 Gateway API 指定将七层代理部署在 ASM 托管的 Waypoint Proxy 池中，或是用户集群内的 ECI Serverless 节点上。
客户案例
丽迅物流是百丽旗下专注于时尚产业、为企业提供专业物流及供应链解决方案的服务商。丽迅物流在全国拥有 70+ 全渠道实体云仓、6 大中心电商仓，总面积达 100 万+ 平方米，服务覆盖 300+ 城市、3000+ 商圈，为多家知名时尚品牌及其品牌门店提供全渠道配送服务。
当前，丽讯物流已将核心生产系统 100% 切换至 ASM，ASM 帮助丽讯物流在网格化落地过程中缩短了至少 50% 的实施周期， 托管化免运维的架构和丰富的产品化能力，也帮助丽讯物流运维团队在网络流量管理、安全配置管理等方面的运维效率至少提升 40%。 丽讯物流切换至 ASM 后，运维人员通过 ASM 提供的各类 API 完成流量规则、安全、可观测相关的所有配置。使用 ASM 网关接入自定义鉴权服务增强了入口安全性，借助 ASM 的外服务注册能力，打通了网格内外服务的通信，通过 ASM 提供的产品化能力高效地接入了统一的可观测平台，获得了从可观测数据生成，到采集，查询、搜索；到仪表盘可视化展示，网格拓扑即时洞察，及网格服务健康评估等整套可观测解决方案。
最后，让我们先来纵览阿里云服务网格提供了哪些企业级服务网格能力。从服务网格能力层面上，包括：异构服务统一治理，多集群、跨集群应用的网络管理，与 CI/CD 工具融合应用的灰度发布与部署，应用云上架构平滑演进，基于 Kserve 的 AI 弹性服务管理等。从集成性与兼容性层面上说，ASM 支持 Web 用户界面，以及提供了完备的 OpenAPI，提供了强大灵活的被集成能力，同时，ASM 完全兼容 Istio 的使用规范，支持通过标准的 K8s API 对服务网格实例的配置进行配置变更。
ASM 控制平面核心组件采用完全托管化设计，标准版与企业版使用统一柔性架构，提供了完备的多版本支持，同时提供了多项包括流量管理增强、协议增强、自适应 XDS 优化、软硬一体优化、网格诊断分析、扩展中心、异构服务注册集成等的强大的定制能力。
ASM 是云原生应用的网络平台，为运行在异构计算基础设施上的应用服务提供统一的网格化治理能力。基于 ASM 强大的异构计算设施支持能力，ASM 帮助用户将运行在 K8s 节点上的工作负载、运行在 ECI 节点的 Serverless 工作负载、以及托管Serverless 组件甚至其他公有云或 IDC 内的工作负载、异构设施打通，进行统一管理和运维。更多 ASM 能力请移步 ASM 首页或通过 ASM 官网文档了解详情。
ASM 首页：
点击此处，查看 ASM Ambient Mesh模式实践教程
