概览

本文概述了 Merbridge 的含义、特性、适用场景等内容。

2 分钟 阅读时间

Merbridge 是什么

Merbridge 专为服务网格设计，使用 eBPF 代替传统的 iptables 劫持流量，能够让服务网格的流量拦截和转发能力更加高效。

eBPF (extended Berkeley Packet Filter) 技术可以在 Linux 内核中运行用户编写的程序，而且不需要修改内核代码或加载内核模块，目前广泛应用于网络、安全、监控等领域。相比传统的 iptables 流量劫持技术，基于 eBPF 的 Merbridge 可以绕过很多内核模块，缩短边车和服务间的数据路径，从而加速网络。Merbridge 没有对现有的 Istio 作出任何修改，原有的逻辑依然畅通。这意味着，如果您不想继续使用 eBPF，直接删除相关的 DaemonSet 就能恢复为传统的 iptables 方式，不会出现任何问题。

Merbridge 有哪些特性

Merbridge 的核心特性包括：

  • 出口流量处理

    Merbridge 使用 eBPF 的 connect 程序，修改 user_ip 和 user_port 以改变连接发起时的目的地址，从而让流量能够发送到新的接口。为了让 Envoy 识别出原始目的地址，应用程序（包括 Envoy）会在收到连接之后调用 get_sockopts 函数，获取 ORIGINAL_DST。

  • 入口流量处理

    入口流量处理与出口流量处理基本类似。需要注意的是，eBPF 是全局性的，不能在指定的命名空间生效。因此，如果对原本不是由 Istio 管理的 Pod 或者对外部的 IP 地址执行此操作，就会导致请求无法建立连接。为了解决此问题，Merbridge 设计了一个小的控制平面（以 DaemonSet 方式部署），通过 Watch 所有的 Pod，用类似于 kubelet 的方式获取当前节点的 Pod 列表，然后将已经注入 Sidecar 的 Pod IP 地址写入 local_pod_ips map。如果流量的目的地址不在该列表中，Merbridge 就不做处理，转而使用原来的逻辑。这样就可以灵活且便捷地处理入口流量。

  • 同节点加速

    在 Istio 中，Envoy 使用当前 PodIP 加服务端口来访问应用程序。由于 PodIP 肯定也存在于 local_pod_ips ，所以请求就会被转发到 PodIP + 15006 端口。这样会造成无限递归，不能在 eBPF 获取当前命名空间的 IP 地址信息。因此，需要一套反馈机制：在 Envoy 尝试建立连接时仍然重定向到 15006 端口，在 sockops 阶段判断源 IP 和目的 IP 是否一致。如果一致，说明发送了错误的请求，需要在 sockops 丢弃该连接，并将当前的 ProcessID 和 IP 地址信息写入 process_ip map，让 eBPF 支持进程和 IP 的对应关系。下次发送请求时直接从 process_ip 表检查目的地址是否与当前 IP 地址一致。Envoy 会在请求失败时重试，且这个错误只会发生一次，后续的连接会非常快。

为什么需要 Merbridge

在服务网格场景中，为了能在应用程序完全无感知的情况下利用边车进行流量治理，需要把 Pod 的出入口流量都转发到边车。在这种情况下，最常见的解决方案就是使用 iptables (netfilter) 的重定向能力。这种方案的缺点是增加了网络延迟，因为 iptables 对出口流量和入口流量都进行拦截。以入口流量为例，原本直接流向应用的流量，需要先由 iptables 转发到边车，再由边车将流量转发到实际的应用。原本只需要在内核态处理两次的链路如今变成四次，损失了不少性能。

幸运的是，eBPF 技术提供了一个 bpf_msg_redirect_hash 函数，可以将应用发出的数据包直接转发到对端的 socket，从而极大地加速数据包在内核中的处理流程。我们希望用 eBPF 技术代替 iptables 提高服务网格的效率，于是 诞生了 Merbridge。

Merbridge 适用哪些场景

如果您遇到下列任一问题，建议使用 Merbridge：

  1. 在需要高性能连接的场景下，使用 iptables 会增加延迟。
    • 由于集群中容器数量增加，iptables 控制面和数据面的性能会急剧下降。在 iptables 控制面的接口设计中，每添加一条规则都需要遍历并修改所有的规则。
    • 由于 Pod 生命周期越来越短，有时甚至只有几秒钟，这就需要快速更新 iptables 规则，使用 IP 地址进行安全过滤的系统将承受越来越大的压力。
    • 由于使用 iptables 实现透明劫持需要借助 conntrack 模块跟踪连接，连接较多时会造成大量消耗。
  2. 系统因某些原因不能使用 iptables。
    • 有时需同时处理大量活动连接，但使用 iptables 容易出现 conntrack 表满的情况。
    • 有时又需每秒处理极大数量的连接，但超出了 conntrack 表的限制。例如，在超时设置为 120 秒且表容量是 128k 的情况下，如果尝试每秒处理 1100 个连接，就会超出 conntrack 表的限制（128k/120秒 = 1092 连接/秒）。
  3. 出于安全考虑不能为普通的 Pod 授予太多权限，但使用 Istio（若无 CNI）必须允许 Pod 获得更多权限。
    • 运行 init 容器，可能需要 NET_ADMIN 等权限。
    • 运行 iptables 命令，对应的进程可能需要 CAP_NET_ADMIN 权限。
    • 挂载文件系统，对应的进程可能需要 CAP_SYS_ADMIN 权限。

Merbridge 如何改变连接关系

使用 eBPF 在主机上处理连接，可以显著简化内核处理流量的流程，提升服务之间的通讯质量。

Merbridge 是完全独立的开源项目，目前仍处于早期阶段。希望有更多的用户或开发者参与其中，不断完善 Merbridge，共同优化服务网格。如果您发现了 Merbridge 的漏洞而且有兴趣帮助修复，非常欢迎您提交 Pull Request，附上您的修复代码，我们会及时处理您的 PR。

最后修改 2022.10.12 : [docs] Fix minor errors (#24) (244310f)