KubeCon 2021｜使用 eBPF 代替 iptables 优化服务网格数据面性能-低调大师

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

2021-12-16 477

作者

刘旭，腾讯云高级工程师，专注容器云原生领域，有多年大规模 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]

Inbound iptables 将入流量重定向到 15006 端口，也就是 envoy 的 VirtualInboundListener，envoy 会根据请求的原始目的地址转发到应用程序的指定端口
Outbound iptables 将出流量重定向到 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 团队将持续探索新的性能优化方向。

Reference

[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

关于我们

更多关于云原生的案例和知识，可关注同名【腾讯云原生】公众号~

福利：

①公众号后台回复【手册】，可获得《腾讯云原生路线图手册》&《腾讯云原生最佳实践》~

②公众号后台回复【系列】，可获得《15个系列100+篇超实用云原生原创干货合集》，包含Kubernetes 降本增效、K8s 性能优化实践、最佳实践等系列。

③公众号后台回复【白皮书】，可获得《腾讯云容器安全白皮书》&《降本之源-云原生成本管理白皮书v1.0》

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！

微信关注我们

原文链接：https://my.oschina.net/u/4534936/blog/5371486

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

【云端技能包】k8s 知识- 模块化方式认识Statefulset和Deployment

在学习干货前，客官请留步——【“云”住民生存训练营--玩转k8s】本周五，即将在线上开播，扫码一键预约直播！当我们使用 k8s 的各种 resource 时，常常会感到 yaml 元素项目繁多、难以记忆，例如api, meta data， spec，template等等。我们在记忆某个选项或者是自己在编写这个选项的时候，可能会感觉比较困难。事实上，k8s 的 resource 描述方式自有其规律在其中。如果能用模块化的方法拆解一下，可以更好地理解记忆它们的相同与不同之处。云资源优化服务 SpotMax无缝集成了Kubernetes，可便捷实现容器的管理与自动化发布。==>戳链接了解SpotMax StatefulSet和Deployment作为我们在 k8s 中常用的控制器（工作负载），以不同方式管理着 Pod。通常情况下，StatefulSet用于部署有状态应用，Deployment 则用于部署无状态应用。这一期“云端跟我学”，我们将以StatefulSet和Deployment为例，用模块化的方式进行对比记忆，并认知其中的规...

2021-12-15

598

摘要：简要介绍XLA的工作原理以及它在 Pytorch下的使用。本文分享自华为云社区《XLA优化原理简介》，作者：拓荒者01。初识XLA XLA的全称是Accelerated Linear Algebra，即加速线性代数。作为一种深度学习编译器，长期以来被作为Tensorflow框架的一个试验特性被开发，历时至今已经超过两三年了，随着Tensorflow 2.X的发布，XLA也终于从试验特性变成了默认打开的特性。此外， Pytorch社区也在大力推动XLA在Pytorch下的开发，现在已经有推出PyTorch/XLA TPU版本，暂只支持谷歌平台TPU上使用。 LLVM 提到编译器就不得不提大名鼎鼎的LLVM。LLVM是一个编译器框架，由C++语言编写而成，包括一系列分模块、可重用的编译工具。 LLVM框架的主要组成部分有： 1、前端：负责将源代码转换为一种中间表示 2、优化器：负责优化中间代码 3、后端：生成可执行机器码的模块 LLVM为不同的语言提供了同一种中间表示LLVM IR，这样子如果我们需要开发一种新的语言的时候，我们只需要实现对应的前端模块，如果我们想要支持一种新的...

2021-12-16

656

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。