KubeCon 2021|使用 eBPF 代替 iptables 优化服务网格数据面性能

语言: CN / TW / HK

作者简介

  刘旭

腾讯云高级工程师,专注容器云原生领域,有多年大规模 Kubernetes 集群管理及微服务治理经验,现负责腾讯云服务网格 TCM 数据面产品架构设计和研发工作。

引言

目前以 Istio[1] 为代表的服务网格普遍使用 Sidecar 架构,并使用 iptables 将流量劫持到 Sidecar 代理,优点是对应用程序无侵入,但是 Sidecar 代理会增加请求时延和资源占用。

性能一直是用户十分关心的一个点,也是用户评估是否使用服务网格产品的关键因素,腾讯云 TCM 团队一直致力于优化服务网格性能,上周我们在 KubeCon 分享了 使用 eBPF 代替 iptables 优化服务网格数据面性能的方案

iptables 实现流量劫持

首先看一下当前社区使用的基于 iptables 的流量劫持方案,下图是一个 Pod 的创建过程,sidecar injector 会向 Pod 中注入两个容器,istio-init 和 istio-proxy。

  • istio-init 是一个 init container,负责创建流量劫持相关的 iptables 规则,在创建完成后会退出;

  • istio-proxy 中运行着 envoy,负责代理 Pod 的网络流量,iptables 会将请求劫持到 istio-proxy 处理。

下图展示了 iptables 完成流量劫持的整个过程,这里简单说明下,感兴趣的同学可以查看[2]

  • Inboundiptables 将入流量重定向到 15006 端口,也就是 envoy 的 VirtualInboundListener,envoy 会根据请求的原始目的地址转发到应用程序的指定端口;

  • Outboundiptables 将出流量重定向到 15001 端口,也就是 envoy 的 VirtualOutboundListener,envoy 会根据请求的原始目的地址以及 Host URL 等信息路由到指定后端。

eBPF 实现流量劫持

eBPF(extended Berkeley Packet Filter) 是一种可以在 Linux 内核中运行用户编写的程序,而不需要修改内核代码或加载内核模块的技术,目前被广泛用于网络、安全、监控等领域。在 Kubernetes 社区最早也是最有影响的基于 eBPF 项目是 Cilium[4],Cilium 使用 eBPF 代替 iptables 优化 Service 性能。

Inbound

首先来看一下对入流量的劫持,对入流量的劫持主要使用 eBPF 程序 hook bind 系统调用完成。

eBPF 程序会劫持 bind 系统调用并修改地址,例如应用程序 bind 0.0.0.0:80 会被修改为 127.0.0.1:80,应用程序还有可能 bind ipv6 的地址,所以这里有两个 eBPF 程序分别处理 ipv4 和 ipv6 的 bind。

和 iptables 不同,iptables 可以针对每个 netns 单独设置规则,eBPF 程序 attach 到指定 hook 点后,会对整个系统都生效,例如 attach 到 bind 系统调用后,所有 Pod 内以及节点上进程调用 bind 都会触发 eBPF 程序,我们需要区分哪些调用是来自需要由 eBPF 完成流量劫持的 Pod。

在 K8s 中,除了 hostnetwork 的情况,每个 Pod 都有独立的 netns,而每个 netns 都有唯一的 cookie,因此我们将需要使用 eBPF 完成流量劫持的 Pod 对应的 netns cookie 保存在 cookie_map 中,eBPF 程序通过判断当前 socket 的 netns cookie 是否在 cookie_map 中来决定是否修改 bind 地址。

修改应用程序的 bind 地址后,还需要下发 pod_ip:80 listener 配置到 envoy,pod_ip:80 listener 会将请求转发到 127.0.0.1:80 也就是应用程序监听的地址,这样就实现了对入流量的劫持。但是这里有一个问题,由于 istio 使用 istio-proxy 用户启动 envoy,默认情况下非 root 用户不能 bind 1024 以下的特权端口,我们通过 istio-init 修改内核参数 sysctl net.ipv4.ip_unprivileged_port_start=0 解决了这个问题。

对比 iptables 和 eBPF 对入流量的劫持,iptables 方案每个包都需要 conntrack 处理,而 eBPF 方案只有在应用程序调用 bind 时执行一次,之后不会再执行,减少了性能开销。

Outbound

再来看一下对出流量的劫持,对出流量的劫持比较复杂, 根据协议分为 TCP 和 UDP 两种情况。

TCP 流量劫持

对 TCP 的出流量劫持过程:

  • _coonect4 通过劫持 connect 系统调用将目的地址修改为127.0.0.1:15001,也就是 envoy 的 VirtualOutboundListerer,同时将连接的原始目的地址保存在 sk_storage_map;

  • 在 TCP 连接建立完成后, sockops 会读取 sk_storage_map 中的数据,并以四元组(源IP、目的IP、源端口、目的端口)为 key 将原始目的地址保存在 origin_dst_map;

  • _getsockopt 通过劫持 getsockopt 系统调用,读取 origin_dst_map 中的数据将原始目的地址返回给 envoy。

UDP 流量劫持

istio 在 1.8 版本支持了智能 DNS 代理[5],开启后 iptables 会将 DNS 请求劫持到 Sidecar 处理,我们也需要用 eBPF 实现相同逻辑,对于 TCP DNS 的劫持和上面类似, 对 UDP DNS 的劫持见下图:

对 UDP 的出流量劫持过程:

  • _connect4 _sendmsg4 都是负责修改 UDP 的目的地址为 127.0.0.1:15053 并保存原始的目的地址到 sk_storage_map ,因为 Linux 提供两种发送 UDP 数据的方式
    • 先调用 connect 再调用 send,这种情况由 _connect4 处理
    • 直接调用 sendto,这种情况由 _sendmsg4 处理
  • recvmsg4 通过读取 sk_storage_map 将回包的源地址改为原始的目的地址,这是因为有些应用程序,例如 nslookup 会校验回包的源地址。

对于 TCP 和 connected UDP,iptables 方案每个包都需要 conntrack 处理,而eBPF 方案的开销是一次性的,只需要在 socket 建立时执行一次,降低了性能开销。

Sockmap

使用 sockmap 优化服务网格性能的方案最早由 cilium 提出,我们的方案也参考了 cilium,这里 借用 cilium 的两张图来说明下优化效果。

优化前 Sidecar 代理与应用程序间的网络通信都需要经过 TCP/IP 协议栈处理。

优化后 Sidecar 代理与应用程序间的网络通信绕过了 TCP/IP 协议栈,如果两个 Pod 在同一节点上,两个 Pod 间的网络通信也可以被优化。这里简单说明下 sockmap 的优化原理,感兴趣的同学可以查看[6][7]。

  • sock_hash 是一个存储 socket 信息的 eBPF map,key 是四元组(源IP、目的IP、源端口、目的端口);
  • _sockops 负责监听 socket 事件,并将 socket 信息保存在 sock_hash;
  • _sk_msg 会拦截 sendmsg 系统调用,然后到 sock_hash 中查找对端 socket,如果找到会调用 bpf_msg_redirect_hash 直接将数据发送给对端 socket。

问题

但是用四元组做为 key 可能会存在冲突的问题,例如在同一节点上的两个 Pod 中,envoy 使用同一源端口 50000 请求应用程序的 80 端口。

为了解决这个问题,我们在 key 中添加了 netns cookie,同时对于非 localhost 的请求将 cookie 设置为 0,这样既保证了 key 不会冲突,又可以加速同一节点上两个 Pod 间的网络通信。

但是之前版本的内核不支持在 sockops sk_msg 这两种 eBPF 程序中获取 netns cookie 信息,因此我们提交了两个 patch [8 ][9]到内核社区,目前已合入 5.15 版本。

架构

整个方案的架构如图所示,istio-ebpf 以 DaemonSet 的形式运行在节点上,负责 load/attach eBPF 程序和创建 eBPF map。istio-init 容器仍然保留,但是不再创建 iptables 规则,而是更新 eBPF map,istio-init 会将 Pod 的 netns cookie 保存在 cookie_map 中。同时我们也修改了 istiod,istiod 会根据 Pod 的流量劫持模式(iptables/eBPF)下发不同的 xDS 配置。

性能对比

测试环境:Ubuntu 21.04 5.15.7

  • 同等条件下,使用 eBPF 可减少 20% 的 System CPU 占用;

  • 同等条件下,使用 eBPF 可提高 20% QPS;

  • 同等条件下,使用 eBPF 可降低请求时延。

总结

服务网格的 Sidecar 架构不可避免的会增加请求时延和资源占用,我们通过使用 eBPF 代替 iptables 实现流量劫持,同时使用 sockmap 加速 Sidecar 代理和应用程序间的网络通信,在 一定程度上降低了请求时延和资源开销 ,由于内核版本等限制这一方案预计会在明年初上线,TCM 团队将持续探索新的性能优化方向。

参考资料

[1] https://istio.io

[2] https://jimmysong.io/blog/sidecar-injection-iptables-and-traffic-routing

[3] https://ebpf.io

[4] https://cilium.io

[5] https://istio.io/latest/blog/2020/dns-proxy

[6] https://arthurchiao.art/blog/socket-acceleration-with-ebpf-zh

[7] https://github.com/cilium/cilium/tree/v1.11.0/bpf/sockops

[8] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=6cf1770d

[9] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fab60e29f