无Sidecar又成为新的趋势了？

Istio的实验性环境网格（Ambient Mesh）号称能大大降低运营复杂性，但Linkerd的拥护者们则认为Sidecar本身并不是问题的关键。

一种新的Istio服务网格架构抛弃了Sidecar代理，凭借显著降低运营复杂性的承诺引得企业IT专业人士纷纷侧目。但竞争对手Linkerd项目的支持者则认为，导致复杂性难题的核心并不是Sidecar架构——而是Envoy代理。

分布式应用程序环境中的服务网格网络方法最早出现在2016年，源自专为虚拟机环境设计的Linkerd 1.0版本。由谷歌、IBM和Lyft支持的Istio则于2017年发布，主要面向的是Kubernetes容器编排环境。Linkerd 2.0紧随其后发布，也开始重点关注Kubernetes。从那时起，容器编排器的日益普及扩大了服务网格的应用范围，着力将应用层和开发者从复杂的微服务网络负担当中解放出来。

直到今年，这些服务网格的基本架构设计都是相同的——两者都使用一种称为Sidecar代理的特殊容器来将网络管理从应用程序当中剥离出来。这些Sidecar代理与应用程序密切相关，作为各个Kubernetes Pod的组成部分。与传统网络相比，这种紧密性也让我们能对应用程序路由和监控进行更细粒度的控制。

但随着服务网格在大规模环境中得到广泛应用，Sidecar代理的局限性也凸显了出来。在对性能高度敏感的环境中，将容器绑定到每个应用程序可能会产生难以承受的开销。因为期间需要重新启动所有Sidecar，这会使服务网格的升级困难重重，可能严重影响应用程序的可用性。

应用程序容器也可能与Sidecar容器不同步，这会产生更多潜在的可靠性问题。在应用程序可能需要服务网格的某些功能的环境中，管理庞大的Sidecar可能产生难以承受的负担。以双向TLS认证（简称mTLS）为例，这些功能发生在开放系统互连模型的较低层——特别是L4层——但并不需要L7层上的完整应用级精细过滤。

Istio Ambient Mesh项目目前处于实验性阶段，由Google和Solo.io的工程师在今年9月份开源。其中包含了一个新的架构，维护人员称它通过服务网格Sidecar回避了这些问题。

Ambient Mesh不会将服务网格的所有功能捆绑到随每个应用程序一起部署的Sidecar中，而是将代理分解为一组两个共享资源，称为DaemonSet，分别部署在每个Kubernetes集群上。IT管理员可以使用相同类型的现有Istio配置文件和Kubernetes应用程序文件，来指示应用程序是否需要L4层或L7层路由功能。Ambient Mesh中的整合代理将据此执行流量路由，而不需要为每个Pod配备一个Sidecar。

这种新方法才刚刚起步，但已经有一些Istio用户表示很想一探究竟。

“这太棒了，我们将尽快采用，”Constant Contact公司首席软件工程师David Ortiz在本周的一次在线采访中说。“它大大简化了Istio的操作，特别是在升级方面。”

一位KubeCon与会者表示，他计划在Ambient Mesh成熟时对其进行仔细评估，并表达了浓厚的兴趣。

有线电视提供商Comcast云服务执行总监Greg Otto本周在接受采访时说：“Sidecar确实发挥过重要的作用，但我们也很希望能以不同的思路服务和扩展L7层和L4层。在边缘场景中，我们非常关注L7层[过滤]，但并不想因此影响到整个[网络]，单独交给L4层[路由]明显更适合。”

Otto说，虽然Sidecar代理出于安全目的提供了最严格的服务分离，但Istio的Envoy代理中的大多数关键常见漏洞披露（CVE）都源自L7层。

“在不需要[L7层过滤]的地方，最好能先把它放一放，”他说。“这样即使存在CVE，我们的攻击面也会小得多。”

Linkerd主动对线：问题不在于Sidecar，而在于Envoy

根据Linkerd缔造者兼Buoyant.io首席执行官William Morgan的说法，还有另一种方法可以减少L7层的关键漏洞以及与Sidecar相关的大部分资源开销：直接弃用Envoy。

“归根结底，Sidecar实际上非常简单——它们在操作上非常简单，不难理解，而且故障和安全域非常清楚，”Morgan说。“问题不在于Sidecar——而是由于Enovy的存在，我们不得不面对一个巨大、多用途、资源匮乏且难以操作的代理。”

过去，对Envoy的支持是Istio相对于Linkerd的一个独特卖点，这也使其成为广受欢迎的云原生计算基金会毕业项目。但由Morgan领导的Linkerd维护者则坚持使用他们自己的代理，该代理专为服务网格而设计，代码库规模和资源需求都比Envoy更小。

因此，一位企业Linkerd用户表示，他认为问题的关键不是打造出无Sidecar服务网格，毕竟Sidecar本身跟简单和透明并不矛盾。

丹麦数字金融服务公司Lunar首席平台架构师Kasper Nissen本周接受采访时表示：“从我们的角度来看，Sidecar既简单又易于理解——它与我们使用的其他容器技术没什么区别。一年半前，我们默认使用全服务网格，相应的资源消耗可能也就增加了10%。跟我们获得的mTLS和详尽可见性效果相比，这并不算多。”

Nissen说，他也遇到过Sidecar代理和Lunar使用的Humio日志分析应用程序间不同步的问题。如果Sidecar重新启动，该服务没有时间转移其本地数据，于是Nissen团队只能“设置超时、听天由命”，坐视部分数据因此丢失。

然而，Morgan和Nissen坚持认为，Sidecar同步问题的根源在于Kubernetes网络的一个更深层次的问题，这个问题在开源社区三年来一直没有解决。默认情况下，没有办法确保各种容器（无论是由Linkerd等服务使用的短期init容器还是常规应用程序容器）按特定顺序启动和停止。2019年曾有一项Kubernetes增强提案尝试解决这个问题，但被拒绝了；社区中的讨论仍在继续，但情况并没有改变。

“如今一切服务都在作为Sidecare进行交付，所以这个问题应该由Kubernetes方面负责解决。”Nissen说。

Morgan也认为，在Kubernetes中解决这个问题才是根治Sidecar同步性挑战的最佳方法。

“云原生世界向来以探索新功能（而非修复旧设计）为先，所以大家对这类提议的兴趣相对不大。但Sidecar将继续成为服务网格的未来，”Morgan说。“我们当然知道Sidecar有缺陷，可正确答案应该是最终通过Kubernetes的调整来解决，而不是大幅改变架构、向基础设施操作中引入更复杂的机制。”

推荐阅读：