Flomesh 服务网格采用 eBPF 实现更高效的流量拦截和通信

在不久前发布的 Flomesh 服务网格 1.3.3 我们引入了 eBPF 功能，用以替代流量拦截方面的实现 iptables。由于 eBPF 对较新内核的依赖，iptables 的实现仍继续提供。同时，得益于 eBPF 网络方面的能力，我们也实现了同节点网络通信的加速。

背景

在服务网格中，iptables 和 eBPF 是两种比较常见的流量拦截方式。

iptables 是一种基于 Linux 内核的流量拦截工具，它可以通过过滤规则来对流量进行控制。它的优点包括：

• 通用性：iptables 工具已经在 Linux 操作系统中被广泛使用，因此大多数的 Linux 用户都熟悉它的使用方法；
• 稳定性：iptables 早已经成为了 Linux 内核的一部分，因此具有较高的稳定性；
• 灵活性：iptables 工具可以根据需要灵活地配置规则，以控制网络流量。

然而，iptables 也存在一些缺点：

• 难以调试：由于 iptables 工具本身较为复杂，因此在进行调试时比较困难；
• 性能问题：iptables 会在内核空间中进行处理，这可能会对网络性能产生影响；
• 处理复杂流量可能存在问题：当涉及到一些复杂的流量处理时，iptables 可能不太适合，因为其规则处理不够灵活。

ebpf 是一种高级的流量拦截工具，它可以通过自定义的程序在 Linux 内核中进行流量拦截和分析。ebpf 的优点包括：

• 灵活性：ebpf 可以使用自定义的程序来拦截和分析流量，因此具有更高的灵活性；
• 可扩展性：ebpf 可以动态加载和卸载程序，因此具有更高的可扩展性；
• 高效性：ebpf 可以在内核空间中进行处理，因此具有更高的性能。

然而，ebpf 也存在一些缺点：

• 较高的学习曲线：ebpf 相对于 iptables 来说比较新，因此需要一些学习成本；
• 复杂性：ebpf 自定义程序的开发可能比较复杂；
• 安全性：由于 ebpf 可以直接操作内核，因此需要谨慎使用以确保安全。

综合来看，iptables 更适合简单的流量过滤和管理，而 ebpf 更适合需要更高灵活性和性能的复杂流量拦截和分析场景。

架构

在 1.3.3 中为了提供 eBPF 特性，Flomesh 服务网格提供了 CNI 实现 osm-cni 和运行于各个节点的 osm-interceptor，其中 osm-cni 可与主流的 CNI 插件兼容。

当 kubelet 在节点上创建 pod，会通过容器运行时 CRI 实现调用 CNI 的接口创建 Pod 的网络命名空间，osm-cni 会在 pod 网络命名空间创建完成后调用 osm-interceptor 的接口加载 BPF 程序并将其附加到 hook 点上。除此以外 osm-interceptor 还会在 eBPF Maps 中维护 pod 信息等内容。

实现原理

接下来介绍下引入 eBPF 后带来的两个特性的实现原理，注意这里会忽略很多的处理细节。

流量拦截

出站流量

下面的图中展示的是出站（outbound）流量的拦截。将 BPF 程序附加到 socket 操作 connect 上，在程序中判断当前 pod 是否被网格纳管，也就是是否注入 sidecar，然后将目标地址修改为 127.0.0.1、目标端口修改为 sidecar 的 outbound 端口 15003。只是修改还不够，还要将原始目的地址和端口保存在 map 中，使用 socket 的 cookie 作为 key。

当与 sidecar 的连接建立成功后，通过附加到挂载点 sock_ops 上的程序将原始目的地保存在另一个 map 中，使用 本地地址 + 端口和远端地址 + 端口 作为 key。后面 sidecar 访问目标应用时，通过 socket 的 getsockopt 操作获得原始目的地址。没错，getsockopt 上也附加了 BPF 程序，程序会从 map 中取出原地目的地址并返回。

入站流量

对于入站流量的拦截，主要是将原本访问应用端口的流量，转发到 sidecar 的 inbound 端口 15003。这里有两种情况：

• 第一种，请求方和服务方位于同一个节点，请求方 sidecar 的 conn