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

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

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

今天，服务网格通常使用一种称为边车模型的架构来实现。该架构将实现上述功能的代码封装到第 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 的好处可供广泛的最终用户使用，同时将数据路径效率和开销讨论与控制平面方面的问题分离。