eBPF将取代服务网格中的边车Sidecars?

21-12-29 banq

服务网格是一个概念,描述了现代云原生应用程序在通信、可见性和安全性方面的要求。这个概念的当前实现涉及在每个工作负载或 pod 中运行 sidecar 代理。边车、侧车 sidecar 代理是解决这些需求的一种非常低效的方法。在这篇文章中,我们将研究 sidecar 模型的替代方案,该模型在 eBPF 的帮助下提供高效、低复杂度的透明服务网格。

 

看看今天服务网格的特性集,可以总结如下:

  • 弹性连接:服务间通信必须能够跨越云、集群和本地等边界。通信必须具有弹性和容错性。
  • L7 流量管理:负载平衡、速率限制和弹性必须是 L7 感知的(HTTP、REST、gRPC、WebSocket 等)。
  • 基于身份的安全:依靠网络标识符来实现安全已经不够了,发送和接收服务都必须能够基于身份而不是网络标识符来相互验证。
  • 可观察性和跟踪:跟踪和指标形式的可观察性对于理解、监控和排除应用程序稳定性、性能和可用性至关重要。
  • 透明性:功能必须以透明的方式提供给应用程序,即无需更改应用程序代码。

在早期,服务网格功能通常以库的形式实现,要求网格中的每个应用程序链接到用应用程序语言框架编写的库。类似的事情在互联网的早期也发生过:回到过去,应用程序过去常常传送自己的 TCP/IP 堆栈!正如我们将在本文中讨论的那样,服务网格正在演变为内核职责,就像网络堆栈一样。

今天,服务网格通常使用一种称为边车模型的架构来实现。该架构将实现上述功能的代码封装到第 4 层代理中,然后依赖于服务之间的流量被重定向到这个所谓的 sidecar 代理。之所以称为 sidecar,是因为每个应用程序都附加了一个代理,就像附加到摩托车上的 sidecar。

这种架构的优点是服务不再需要自己实现服务网格功能。如果部署了许多用不同语言编写的服务,或者您正在运行不可变的 3rd 方应用程序,这将非常有用。

这种模型的缺点是大量的代理、许多额外的网络连接,以及将网络流量馈送到代理的复杂重定向逻辑。最重要的是,可以将哪种类型的网络流量重定向到第 4 层代理也存在限制。代理在它们可以支持的网络协议方面受到限制。

  

Sidecar注入的成本

如果我们仔细观察 sidecar 模型,我们会注意到它实际上所有东西都被塞进了 Linux 内核的网络命名空间中。然而,它比看起来更复杂,需要许多额外的步骤来透明地注入,这种额外的复杂性带来了延迟和额外资源消耗方面的巨大成本。早期的基准测试表明,这可能会影响高达 3-4 倍的延迟,并且所有代理都需要大量的额外内存。我们将在本文稍后将其与基于 eBPF 的模型进行比较时进行研究。

  

使用 eBPF 解锁内核服务网格

为什么我们之前没有在内核中创建服务网格?有些人半开玩笑地说 kube-proxy 是原始的服务网格,这是有道理的。Kube-proxy 是一个很好的例子,它展示了 Linux 内核在依赖 iptables 实现的基于网络的传统功能的同时,可以多么接近地实现服务网格。但是,这还不够,缺少 L7 上下文。Kube-proxy 专门在网络数据包级别运行。现代应用程序需要 L7 流量管理、跟踪、身份验证和额外的可靠性保证。Kube-proxy 无法在网络级别提供此功能。

eBPF 改变了这个等式。它允许动态扩展 Linux 内核的功能。我们一直在为 Cilium 使用 eBPF 来构建一个高效的网络、安全性和可观察性数据路径,该数据路径将自身直接嵌入到 Linux 内核中。应用相同的概念,我们也可以在内核级别解决服务网格需求。事实上,Cilium 已经实现了各种必需的概念,例如基于身份的安全性、L3-L7 可观察性和授权、加密和负载平衡。丢失的部分现在来到 Cilium。您将在本博客的末尾找到有关如何加入由 Cilium 社区推动的 Cilium 服务网格测试版计划的详细信息。

 

你们中的一些人可能想知道为什么 Linux 内核社区不直接解决这些要求。eBPF 具有巨大的优势。eBPF 代码可以在运行时插入到现有的 Linux 内核中,类似于 Linux 内核模块,但与内核模块不同的是,它可以以安全和可移植的方式完成。这允许 eBPF 实现继续与服务网格社区一起发展。新的内核版本需要数年时间才能交付到用户手中。eBPF 是使 Linux 内核能够跟上快速发展的云原生技术堆栈的关键技术。

 

。。。

详细点击标题

 

结论

eBPF是提供原生且高效的服务网格实现的答案。它将使我们摆脱 sidecar 模型,并允许将现有的代理技术集成到现有的内核命名空间概念中,使它们成为我们每天已经使用的漂亮容器抽象的一部分。最重要的是,eBPF 将能够卸载越来越多的当前由代理执行的功能,以进一步降低开销和复杂性。通过能够集成几乎所有现有的代理,该架构还允许与大多数现有的服务网格控制平面(Istio、SMI、Linkerd 等)集成。这将使 eBPF 的好处可供广泛的最终用户使用,同时将数据路径效率和开销讨论与控制平面方面的问题分离。

 

猜你喜欢