使用 EBPF加速 ISTIO 数据平面

关注

最新推荐文章于 2026-08-07 15:29:08 发布 · 1.4k 阅读

原创 ·

本内容遵循 CC 4.0 BY-SA 版权协议

深入了解服务网格数据平面性能和调优在腾讯，已经有很多产品已使用或者正在尝试使用istio来作为其微服务治理的基础平台。不过在使用istio时，也有一些对通信性能要求较高的业务会对istio的性能有一些担忧。由于envoy sidecar的引入，使两个微服务之间的通信路径变长，导致服务延时受到了一些影响，istio社区一直以来也有这方面的声音。基于这类抱怨，我们希望能够对这一通信过程进行优化，以更好的满足更多客户的需求。首先，我们看一下istio数据面的通信模型，来分析一下为什么会对延时有这么大的影响。可以看到，相比于服务之间直接通信，在引阅读详情

‍

新钛云服已为您服务1382天

介绍：

服务网格是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。Istio 是迄今为止最受欢迎的服务网格，因为它有非常丰富的功能。

本文提出了一种优化默认数据平面的方法，并使用新的内核定制机制——EBPF 来加速它。这篇文章是三部曲的第一部分。它介绍了背景知识以更好地理解我们的想法，并概括了实现加速目标的一些关键步骤。

EBPF

Extended Berkeley Packet Filter (eBPF) 是 Linux 内核中一种高度灵活和高效的虚拟式构造，允许它以安全的方式在各种挂钩点执行字节码。它在很多 Linux 内核子系统中被使用，而且它是最突出的是网络、跟踪和安全的工具。

eBPF 的工作流程图如上

PROGRAM TYPE

目前，有很不同的 Berkeley Packet Filter (BPF) 程序类型可用；下面的几个小节解释了两种主要的联网方式。

SOCK_OPS

BPF_PROG_TYPE_SOCK_OPS（简称sock_ops）允许这种类型的BPF程序访问socket的一些字段（如IP地址、端口等）。它在网络堆栈代码的不同位置被多次调用。

此外，它使用现有的 BPF cgroups 基础结构，因此程序可以附加到每个 cgroup 并具有完全继承支持。我们使用 sock_ops 来捕获满足我们要求的套接字并相应地将它们添加到映射中。

SOCK_MSG

BPF_PROG_TYPE_SK_MSG（简称sock_msg）可以附加到sockhash map上，捕获map中socket发送的每一个数据包，并根据msg的字段（如IP地址、端口等）确定其目的地。

HELPER FUNCTION

辅助函数使 BPF 程序能够查询核心内核定义的一组函数调用，以从内核检索数据或将数据推送到内核。每种 BPF 程序类型的可用辅助函数可能不同。例如，与附加到 TC 层的 BPF 程序相比，附加到套接字的 BPF 程序只允许调用帮助程序的子集。下面解释了一个辅助函数。

BPF_MSG_REDIRECT_HASH

此帮助程序用于在套接字级别实现策略的程序。如果消息 msg 被允许通过（即如果判定 eBPF 程序返回 SK_PASS），则使用哈希 key 将其重定向到 map（类型 BPF_MAP_TYPE_SOCKHASH）引用的套接字.

MAP

映射是驻留在内核空间中的高效键/值存储。可以从 BPF 程序访问它们以保持多个 BPF 程序调用之间的状态。它们也可以从用户空间通过文件描述符访问，并且可以与其他 BPF 程序或用户空间应用程序任意共享。

SOCKHASH

Sockhash 和 Sockmap 是用于存储内核打开的套接字的数据结构。Sockmap 当前由一个数组支持，并将键强制为四个字节。这适用于许多用例。但是，在 Sockhash 更合适的更大用例中，这已成为限制。当调用Sockhash上的Sock_msg程序重定向msg时，5元组查找键可以保证尽快找到对端socket。

ISTIO 中的数据平面

Istio 服务网格在逻辑上分为数据平面和控制平面。控制平面管理和配置代理以路由流量。数据平面由一组部署为边车的智能代理 (Envoy) 组成。这些代理中介和控制微服务之间的所有网络通信，这是我们优化的重点。

边车模式

在 pod 的启动阶段，一个 sidecar 容器和一个 init 容器被注入到应用程序清单中。流量从应用程序服务传入和传出这些 sidecar，开发人员无需担心。Sidecar 代理通过在 pod 命名空间中设置 iptable 规则来获取进出容器的入站和出站流量。

进入应用程序 pod 命名空间并获取配置的 iptables，如下所示。

$ nsenter -t 4215 -n iptables -t nat -S

-P PREROUTING ACCEPT

-P INPUT ACCEPT

-P OUTPUT ACCEPT

-P POSTROUTING ACCEPT

-N ISTIO_INBOUND

-N ISTIO_IN_REDIRECT

-N ISTIO_OUTPUT

-N ISTIO_REDIRECT

-A PREROUTING -p tcp -j ISTIO_INBOUND

-A OUTPUT -p tcp -j ISTIO_OUTPUT

-A ISTIO_INBOUND -p tcp -m tcp --dport 80 -j ISTIO_IN_REDIRECT

-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001

-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT

-A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN

-A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN

-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN

-A ISTIO_OUTPUT -j ISTIO_REDIRECT

-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001

ISTIO中APP和SIDECAR之间的流量

Pod 流量可以分为三类，按其方向定义：Inbound、Outbound 和 Envoy to Envoy。我们将在下面的小节中使用从客户端服务到服务器服务的请求示例来解释这三个类别。

Outbond

当应用程序向远程服务发送请求消息时，该消息通过另一个应用程序（客户端）创建的套接字作为内核空间中的套接字缓冲区（SKB）发送。它遍历网络堆栈，直到被 iptables 规则在 netfilter 级别拦截。它使用新目的地完成网络堆栈中剩余的旅行路径。套接字在 Envoy 创建的环回接口上侦听具有静态 ip 和端口 (127.0.0.1:15001) 的出站流量。

ENVOY TO ENVOY (同一主机)

在 Envoy 处理完请求消息后，它会相应地向托管服务器服务的 pod 发送一条消息。SKB 通过在服务器端网络命名空间中设置的 iptables 规则拦截消息，并将其重定向到 Envoy 正在侦听的默认端口 (pod_ip:15006) 以处理入站流量。

Inbond

Envoy 处理完请求消息后，使用环回地址（127.0.0.1）访问服务器服务。SKB经过两次网络栈，最终到达服务器端。

加速的工作原理

套接字到套接字的重定向

eBPF 允许我们将 SKB 从套接字重定向到套接字，从而节省了遍历网络堆栈其余部分的成本。下图说明了加速后的交通流量。

区分套接字对并将其添加到HASHMAP

Sock_ops 允许我们根据连接信息（例如 IP 地址、端口号等）来区分套接字。要从套接字重定向到套接字，我们需要连接的套接字对，然后将它们添加到 sockhash 映射中以备下一步使用。

哈希映射中套接字的重定向

SKB_ops 附加到一个哈希映射，捕获映射中套接字发送的每个 SKB 并确定其目的地。要将 SKB 发送到对等套接字，请将目标的 4 元组信息（src ip、src 端口、dest ip、dest 端口）作为参数传递给重定向辅助函数。它在 sockhash 映射中搜索对等套接字并在它找到了。否则，它会像过去一样继续遍历网络堆栈。