无Sidecar成新趋势,将是服务网格的未来?

分布式实验室 2022-12-31 10:42:00

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的调整来解决,而不是大幅改变架构、向基础设施操作中引入更复杂的机制。”

 

作者丨韩兵
来源丨公众号:分布式实验室(ID:DistributedLab)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
活动预告