共计 4325 个字符，预计需要花费 11 分钟才能阅读完成。
文|田阳 （花名：烈元）
MOSN Maintainer
专一云原生等技术畛域
本文 3042 字 浏览 10 分钟
1. 背景
Service Mesh 被越来越多的公司认可并实际，在理论落地过程中也遇到了不拘一格的问题，同时架构也在继续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd；有的从做 CNI 延长到 Service Mesh 场景，联合 eBPF 应用 DaemonSet mode，如 Cilium；现在 Istio 也新增了 Ambient Mesh，反对 DaemonSet mode 作为其主推模式。
不难看出一个演进趋势就是围绕着是否须要 Sidecar 而开展，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要剖析，最初也将介绍蚂蚁在这方面的摸索和实际。
2. 社区趋势
2.1 Cilium
Cilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、爱护和察看容器工作负载之间的网络连接。
在 6 月份，Cilium 公布了 1.12 版本，其中公布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式：
通过图表咱们能够发现：针对 L3/L4 的能力，Cilium 应用内核的 eBPF 间接反对；对于 L7 的局部能力，将应用 DaemonSet 部署的 Envoy 来反对。Cilium 认为大部分能力都不须要 L7 的参加，通过 eBPF 就能满足，所以 Cilium 也称本人为内核级服务网格。
针对于此 Cilium 也有一个解释，联合应用程序 TCPD 最终被合入 linux kernel 倒退为 iptables 为例，认为 Mesh 也应该作为根底能力下沉到 linux kernel 作为网络的根底组件，就相似于 TCP，作为 Linux 的一部分通明地提供的服务。
在当须要 L7 代理能力的时候，会构建 DaemonSet Envoy 解决 L7 的能力。Envoy 也曾经有了 Namespace 的初步概念，它们被称为监听器。监听器能够携带独自的配置并独立运行，从而能够反对多租户的配置隔离 (但目前还做不到资源和故障的隔离）。
Cilium 认为 DaemonSet 相比 Sidecar 最显著的益处就是代理数大大减少，缩小资源和治理老本。
能够看出 Cilium Service Mesh 的倒退历程是由下而上，从内核层缓缓向业务层扩大本人的服务边界，由 eBPF 来反对服务网络也是有肯定的立场因素。但 eBPF 并不是银弹，DaemonSet mode 也是有一些其余的问题，收益和损失都是绝对的。
2.2 Linkerd
当然，Cilium 这个架构也不乏有挑战者，其中来头最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的创始人 William Morgan，比拟有意思的是 Linkerd 最开始的架构是 DaemonSet mode，在前面的版本才换成 Sidecar mode，对于此，作为逆行者的他应该最有发言权。
在 William Morgan 的最新文章[3] 中也主观提出了 eBPF 的一些局限性，为了保障 eBPF 的平安执行而不影响 kernel，须要通过验证器验证是否有不正确的行为，这就导致 eBPF 的编写存在肯定的潜规则，比方不能有无界循环；不能超过预设的大小等，代码的复杂性也就受到了肯定限度。所以较简单的逻辑用 eBPF 来实现也是有较高的老本的。
文章中也提到了 DaemonSet 的一些弊病：
– 资源管理不可评估：这取决于 K8s 调度多少 Pod 到该 Node；
– 隔离性：所有利用专用一个 Proxy，相互影响稳定性；
– 爆炸半径变大：影响整个 Node 的 Pod 实例；
– 平安问题更简单：比方 Proxy 保留有整个 Node 的秘钥。
简而言之，Sidecar 模式持续贯彻了容器级别的隔离爱护 —— 内核能够在容器级别执行所有平安爱护和偏心的多租户调度。容器的隔离依然能够完满的运行，而 DaemonSet 模式却毁坏了这所有，从新引入了争抢式的多租户隔离问题。
当然他也认为 eBPF 能够更好的促成 Mesh 的倒退，eBPF+Sidecar 的联合是 Mesh 的将来。
咱们也比拟认可他对于 eBPF 的认识，eBPF 就像是一把瑞士军刀，玲珑精湛，作为胶水把各种网络数据面连接起来，提供根底网络能力，比方提供拜访减速，通明劫持，网络可察看性等能力。但要开发简单的业务能力，在实操之后，感觉还是有点力不从心。目前咱们团队也正在应用 eBPF 开发 K8s Service 和通明拦挡等根底网络能力。
William Morgan 的说法看着也不无道理，咱们先不急着站队，再来看看 Istio 是怎么做的，看是否会有新的想法~
2.3 Istio
在 9 月份，Service Mesh 畛域的当家花旦 Istio 毫无征兆的公布了 Ambient Mesh，并作为本人后续的主推架构，简略来讲就是把数据面从 Sidecar 中剥离进去独立部署，Sidecarless 架构，以彻底解决 Mesh 基础设施和利用部署耦合的问题。
比拟好奇 Istio 在没有通过社区探讨和落地案例的状况下，是怎么决策笃定这个新的架构方向的呢？
Istio 认为 Sidecar mode 存在如下三个问题：
– 侵入性
必须通过批改应用程序的 Kubernetes pod spec 来将 Sidecar 代理“注入”到应用程序中，并且须要将 Pod 中利用的流量重定向到 Sidecar。因而装置或降级 Sidecar 须要重新启动利用 Pod，这对工作负载来说可能是破坏性的。
– 资源利用有余
因为每个 Sidecar 代理只用于其 Pod 中相干的工作负载，因而必须针对每个 Pod 可能的最坏状况激进地配置 Sidecar 的 CPU 和内存资源。这导致了大量的资源预留，可能导致整个集群的资源利用有余。
– 流量中断
流量捕捉和 HTTP 解决 通常由 Sidecar 实现，这些操作的计算成本很高，并且可能会毁坏一些实现和 HTTP 协定不齐全兼容的应用程序。
Envoy 的创始人也来凑了个冷落，他对 Sidecar 架构也是颇有微词。
咱们在落地过程中也是遇到了相似的痛点，比方随着机房规模和利用规模的变大，利用的连接数持续收缩导致 CPU 和 MEM 资源占用也在继续减少，但这所有都不是利用自身想去关怀的。
那么让咱们来解开 Ambient Mesh 架构真面目，是怎么来解决 Sidecar mode 的问题，架构次要提出了分层：
从图中能够看出，跟 Cilium 有一些相似，这儿的两层数据面都是基于 Envoy 来构建的，Secure Overlay Layer 次要解决 L4 场景，DaemonSet 部署，L7 processing Layer 次要解决 L7 场景，以 gateway 模式通过 Pod 部署，一个利用部署一个 gateway。
图中的 ztunnel 就是 L4 （DaemonSet 部署），waypoint 就是 L7 （Pod 部署），L4 和 L7 都是可选的，能够依据业务场景灵便组合，比方没有 L7 的场景，间接就用 L4 即可。
注：图中的 ztunnel 就是 L4 （DaemonSet 部署），waypoint 就是 L7 （Pod 部署）。
无形之中，Ambient Mesh 架构对 William Morgan 评论中的问题也做了肯定的解决和反驳：
– 资源评估
Istio 认为 L4 资源占用少，而后 L7 的资源占用是通过 Pod 部署，能够更好的弹性。
– 隔离性
每个利用都将有一个 L7 集群，互相不影响。
– 爆炸半径
L4 逻辑简略绝对比较稳定，L7 独立部署，也只影响本身利用。
– 平安问题
Istio 认为 Envoy 作为被世界上最大的网络运营商应用的久经考验的成熟软件，它呈现安全漏洞的可能性远低于与它一起运行的应用程序。DaemonSet 模式下，呈现平安问题时的影响范畴并不比任何其余依赖每节点密钥进行加密的 CNI 插件差。无限的 L4 攻击面和 Envoy 的平安个性，Istio 感觉这种危险是无限和能够承受的。
针对 William Morgan 提到的 DaemonSet 减少了平安危险，咱们也持保留意见，就拿证书场景为例，在没有对立接入层 （南北向接入网关） 这个产品之前 （15 年前，还没有 K8s），利用的 HTTPS 证书和私钥都是放在跟利用一起部署的 Tengine 上，就相似于 Sidecar 模式，但接入层诞生的一个起因恰好就是为了集中管理证书和私钥来缩小平安危险，通过证书和私钥的拆散架构，私钥独自寄存在更加平安的 key 集群，并且通过 QAT 硬件加速，HTTPS 性能也更加高效。
把 HTTPS 和 L7 服务治理能力从利用空间解耦进去下沉为基础设施，也让咱们有更多的机会去做集中的优化和演进，同时也对利用更加通明，那个时代的以利用为核心。
对立接入层和目前 Service Mesh 的 DaemonSet mode 有着不少相似之处，DaemonSet mode 也能够认为是一个货色流量的 Node 接入层。
网络通信作为基础设施，和利用齐全解耦后，能够更好的优化和演进，也能更加通明高效的为利用提供相干根底能力，比方网络连接治理，可信身份，链路加密，流量镜像，平安隔离，服务治理等，更好的以利用为核心。
从 Cilium 到 Linkerd，再到 Istio，几大社区互相切磋，归根结底还是大家的业务场景不一样，也或者是立场不一样。在安全性，稳定性，治理老本，资源占用上，总是会有一个侧重点，这是须要依据不同的业务场景去抉择，脱离业务场景谈架构，还是比拟空洞。
3. 下一站
没有最好的架构，只有最适宜本人的架构，在大家的业务场景，你会抉择 Sidecar，还是 Sidecarless，你认为的下一站是什么呢？
下周咱们行将公布《降本增效: 蚂蚁在 Sidecarless 的摸索和实际》，一起来聊聊蚂蚁在这个方向的摸索和演进，期待和大家的交换~
4. 援用
[1]Cilium :
https://istio.io/latest/blog/2022/introducing-ambient-mesh/
[2]Linkerd :
https://isovalent.com/blog/post/cilium-service-mesh/
[3]William Morgan 的最新文章:
https://buoyant.io/blog/ebpf-sidecars-and-the-future-of-the-service-mesh
MOSN Star 一下✨：
https://github.com/mosn/mosn
本周举荐浏览
蚂蚁团体 Service Mesh 停顿回顾与瞻望
[顺丰科技 Service Mesh：落地半年，最后指标曾经实现，将在更多场景进行大规模摸索
](http://mp.weixin.qq.com/s?__b…)
「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实际
MOSN 反向通道详解
