近日(美国东部时间7月12日),CNCF通过官网宣布,Istio正式成为毕业项目,理由是作为一个快速增长的服务网格产品,为该领域增添了更多的终端用户、产品特性和维护者,达到了基金会的最高成熟度。
这距离Istio加入CNCF也仅仅过去1年的时间。
如果将Istio诞生的2017年看作服务网格元年,那么到今天为止,它已经走过了6个年头。
作为该领域的典型代表,Istio的发展历程可以看做是服务网格的浓缩史。历经多年的演进和迭代,Istio也从萌新转向成熟,它在流量控制、安全和可观测方面的能力也被越来越多的人所了解。
而服务网格领域的开发者们依然在探索着各种新的可能性。本文会基于服务网格的架构演化来阐述目前有哪些新的产品形态和技术方向值得我们关注。
网络形态的演化
主流的服务网格产品包括控制平面和数据平面两部分。其中数据平面的构建形态体现了服务网格的主要特征。这是因为所谓网格,指的是由服务间通信链路组成的网络拓扑,以及负责流量控制的代理而组成。业界也主要基于提供核心流控能力的代理组件进行优化和调整。下面我们逐一对目前所出现的各种架构模式进行分析,并探讨它们的优劣和适用场景。
01
Sidecar 模式
一般来说,典型的服务网格都在使用Sidecar作为数据平面,但Sidecar模式并不是服务网格所特有的。
Kubernetes的Pod提供了多容器支持,所有伴随应用容器部署的其他容器都可以被称为Sidecar,如日志收集、追踪代理等。
服务网格将具有流控能力的代理以Sidecar部署,从而组成了网格数据平面的基本形态。
相对于传统服务治理方案(本质上是以SDK方式提供能力)来说,云原生环境下,借助于Kubernetes的能力,以Sidecar模式实现流控和治理是非常直接的一种实现思路,在某种程度上解决了传统方案的弊端,因此也成为了标准的服务网格实现方式。SDK类库或框架具有如下的缺点:
对于异构系统来说,SDK很难提供一个统一的、跨语言、跨系统的服务治理解决方案。Sidecar借机杀入服务治理战场,逐渐成为企业落地时重点考量的选项。到今天为止,绝大多数服务网格产品都以Sidecar模式作为数据平面的标准。随着落地实践的普及,Sidecar的缺点也逐渐被人所熟知:
也正因为如此,社区的开发者开始重新思考是否应该将服务网格和Sidecar划上等号,同时继续探索产品形态其他的可能性。
02
Proxyless 模式
Sidecar本质上是一个服务代理(如Envoy),通过劫持发送到应用容器的流量从而实现对流量的控制。解决代理模式缺点的方案之一就是Proxyless,即无代理模式。其核心理念是:服务间总是要选择一种协议进行通信,就必然要依赖于该协议的类库(SDK)进行编解码工作。既然如此,那么将协议的类库扩展,使其具有流量控制的能力,不就能代替Sidecar代理了吗?且SDK和应用同属于同一进程,必然有更优秀的性能表现,Sidecar最为诟病的延迟问题也会迎刃而解。
2021年Istio官方博客发表了一篇基于gRPC实现Proxyless的文章,详细阐述了其工作原理以及如何在Istio中使用它。如下图所示,在这种模式中,核心的流控能力被集成在gRPC库中,不再使用代理进行数据面通信。但它仍然需要一个Agent进行初始化并与控制平面交互,负责告知gRPC库如何连接到istiod,如何获取证书,并作为xDS代理,代表应用与istiod进行连接和认证。
相比通过进程外通信的Sidecar代理来说,Proxyless具有如下明显的优势:
从官方博客给出的数据来看,gRPC Proxyless模式下的延迟情况接近基准测试,资源消耗也相对较低。
读者可能已经发现,所谓Proxyless其实和传统的SDK并无二致,只是将流控能力内嵌到负责通信协议的类库中,因此它具有和传统SDK服务框架相同的缺点:
也正因为如此,业内很多人认为Proxyless本质上是一种倒退,是回归到传统的方式去解决服务通信的问题。笔者认为,软件设计的主要活动就是取舍,不存在一种完美的方案能解决所有问题。但不管怎样,服务网格领域的开发者们仍旧在探索和推动产品的演进,这才是我们最希望看到的结果。
03
Sidecarless 模式
如果说Sidecar是主流的服务网格架构形态的集大成者,围绕着Sidecar的夺位之争也在持续上演。既然有了去代理模式,那又何妨多个去边车模式?这就是所谓的Sidecarless,也叫Sidecar-free。2022年Cilium基于ebpf技术发布了具有服务网格能力的产品。Cilium的服务网格产品提供了两种模式,对于L3/L4层的能力直接由ebpf支持,L7层能力由一个公共的代理负责,以DaemonSet方式部署。
Cilium认为,内核加上共享型代理的引入可以极大的减少代理的数量,从而降低资源消耗和维护成本。而在内核层面进行通信管理也提高了性能。
但同样,软件领域没有银弹,Sidecarless也是取舍后的结果。ebpf并不是万能钥匙,也存在内核版本要求、编写难度大、安全等方面的问题。Linkerd创始人William Morgan还总结了共享型代理存在的一些缺点:
依笔者愚见,基于ebpf的服务网格在设计思路上其实和Proxyless如出一辙,即找到一个非Sidecar的地方去实现流量控制能力。它们一个是基于通信协议类库,一个是基于内核的扩展性。ebpf通过内核层面提供的可扩展能力,在流量经过内核时实现了控制、安全和观察的能力,从而构建出一种新形态的服务网格。
04
Ambient Mesh
2022年9月Istio发布了一个名为“Ambient Mesh”的无边车数据平面模型,宣称用户可以弃用Sidecar,以Ambient Mesh模式使用Istio的特性。Ambient Mesh将Istio的功能分为两层,安全覆盖层用来处理L4层的路由和安全。如果需要,用户可以启用L7处理层从而使用更全面的功能特性。在这一点上它和Cilium的做法类似。
下图中ztunnel即为安全覆盖层,以DaemonSet部署,本质上是一个处理L4层场景的共享代理。图中的Waypoint代理以Pod形态部署于集群中,可使用Istio处理L7网络的完整能力。
我们可以将Ambient Mesh也看做是一种Sidecarless模式,但笔者更愿意将其称之为中心化代理模式,因为其核心思路是通过共享的、中心化的代理实现流量控制,从而代替应用容器旁的Sidecar代理。不过用户依然可以根据需要同时启用Ambient Mesh和Sidecar,因为它们的关系是互补而不是互斥的。
从官方的博客来看,Istio在过去的半年中一直在推进Ambient Mesh的开发,并于2023年2月将其合并到了Istio的主代码分支。这也从一定程度上说明Istio未来的发展方向之一就是持续的对Ambient Mesh改进并探索多种数据平面的可能性。
05
未来的主角
经过6年多的发展,服务网格已经迈进了早期主流(early majority)技术的行列。借助于新技术和新思路的不断涌现,架构形态也从最初的Sidecar模式变的更加多样化。我们现在很难定论谁会成为最终的胜利者,毕竟各个模式都存在优劣点,都有自己更适合的应用场景。也许服务网格也和程序设计语言一样,并不会出现统一的局面,而是在不断的自我完善中提供给用户更多的选择。
欢迎阅读《Istio最佳实战》一书了解更多相关内容。
本文分享自 博文视点Broadview 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!