利用 eBPF 支撑大规模 Kubernetes Service

【编者的话】本文翻译自 2019 年 Daniel Borkmann 和 Martynas Pumputis 在 Linux Plumbers Conference 的一篇分享：《 Making the Kubernetes Service Abstraction Scale using eBPF 》。翻译时对大家耳熟能详或已显陈旧的内容（Kubernetes 介绍、Cilium 1.6 之前的版本对 Service 实现等）略有删减，如有需要请查阅原 PDF（文末有下载方式）。

实际上，一年之后 Daniel 和 Martynas 又在 LPC 做了一次分享，内容是本文的延续：《基于 BPF/XDP 实现 Kubernetes Service 负载均衡（LPC，2020）》。

以下是译文。

Kubernetes 当前重度依赖 iptables 来实现 Service 的抽象。对于每个 Service 及其 backend pods，在 Kubernetes 里会生成很多 iptables 规则。例如 5K 个 Service 时，iptables 规则将达到 25K 条，导致的后果：

较高、并且不可预测的转发延迟（packet latency），因为每个包都要遍历这些规则，直到匹配到某条规则；
更新规则的操作非常慢：无法单独更新某条 iptables 规则，只能将全部规则读出来，更新整个集合，再将新的规则集合下发到宿主机。在动态环境中这一问题尤其明显，因为每小时可能都有几千次的 backend pods 创建和销毁；
可靠性问题：iptables 依赖 Netfilter 和系统的连接跟踪模块（conntrack），在大流量场景下会出现一些竞争问题（race conditions）；UDP 场景尤其明显，会导致丢包、应用的负载升高等问题。

本文将介绍如何基于 Cilium/BPF 来解决这些问题，实现 Kubernetes Service 的大规模扩展。

Kubernetes Service 类型及默认基于 kube-proxy 的实现

Kubernetes 提供了 Service 抽象，可以将多个 backend pods 组织为一个逻辑单元（logical unit）。Kubernetes 会为这个逻辑单元分配虚拟 IP 地址（VIP），客户端通过该 VIP 就能访问到这些 pods 提供的服务。

下图是一个具体的例子。

73aEBzq.png!mobile

右边的 yaml 定义了一个名为 nginx 的 Service，它在 TCP 80 端口提供服务，创建：kubectl -f nginx-svc.yaml
Kubernetes 会给每个 Service 分配一个虚拟 IP，这里给 nginx 分的是 3.3.3.3，查看：kubectl get service nginx
左边是 nginx Service 的两个 backend pods（在 Kubernetes 对应两个 endpoint），这里位于同一台节点，每个 Pod 有独立的 IP 地址，查看：kubectl get endpoints nginx

上面看到的是所谓的 ClusterIP 类型的 Service。实际上，在 Kubernetes 里有几种不同类型的 Service：

ClusterIP
NodePort
LoadBalancer
ExternalName

本文将主要关注前两种类型。

Kubernetes 里实现 Service 的组件是 kube-proxy，实现的主要功能就是将访问 VIP 的请求转发（及负载均衡）到相应的后端 pods。前面提到的那些 iptables 规则就是它创建和管理的。

另外，kube-proxy 是 Kubernetes 的可选组件，如果不需要 Service 功能，可以不启用它。

ClusterIP Service

这是 Kubernetes 的默认 Service 类型，使得宿主机或 Pod 可以通过 VIP 访问一个 Service。

Virtual IP to any endpoint (pod)
Only in-cluster access

kube-proxy 是通过如下的 iptables 规则来实现这个功能的：

-t nat -A {PREROUTING, OUTPUT} -m conntrack --ctstate NEW -j KUBE-SERVICES



# 宿主机访问 nginx Service 的流量，同时满足 4 个条件：

# 1. src_ip 不是 Pod 网段

# 2. dst_ip=3.3.3.3/32 (ClusterIP)

# 3. proto=TCP

# 4. dport=80

# 如果匹配成功，直接跳转到 KUBE-MARK-MASQ；否则，继续匹配下面一条（iptables 是链式规则，高优先级在前）

# 跳转到 KUBE-MARK-MASQ 是为了保证这些包出宿主机时，src_ip 用的是宿主机 IP。

-A KUBE-SERVICES ! -s 1.1.0.0/16 -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-MARK-MASQ

# Pod 访问 nginx Service 的流量：同时满足 4 个条件：

# 1. 没有匹配到前一条的，（说明 src_ip 是 Pod 网段）

# 2. dst_ip=3.3.3.3/32 (ClusterIP)

# 3. proto=TCP

# 4. dport=80

-A KUBE-SERVICES -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-NGINX



# 以 50% 的概率跳转到 KUBE-SEP-NGINX1

-A KUBE-SVC-NGINX -m statistic --mode random --probability 0.50 -j KUBE-SEP-NGINX1

# 如果没有命中上面一条，则以 100% 的概率跳转到 KUBE-SEP-NGINX2

-A KUBE-SVC-NGINX -j KUBE-SEP-NGINX2



# 如果 src_ip=1.1.1.1/32，说明是 Service->client 流量，则

# 需要做 SNAT（MASQ 是动态版的 SNAT），替换 src_ip -> svc_ip，这样客户端收到包时，

# 看到就是从 svc_ip 回的包，跟它期望的是一致的。

-A KUBE-SEP-NGINX1 -s 1.1.1.1/32 -j KUBE-MARK-MASQ

# 如果没有命令上面一条，说明 src_ip != 1.1.1.1/32，则说明是 client-> Service 流量，

# 需要做 DNAT，将 svc_ip -> pod1_ip，

-A KUBE-SEP-NGINX1 -p tcp -m tcp -j DNAT --to-destination 1.1.1.1:80

# 同理，见上面两条的注释

-A KUBE-SEP-NGINX2 -s 1.1.1.2/32 -j KUBE-MARK-MASQ

-A KUBE-SEP-NGINX2 -p tcp -m tcp -j DNAT --to-destination 1.1.1.2:80

Service 既要能被宿主机访问，又要能被 Pod 访问（二者位于不同的 netns），因此需要在 PREROUTING 和 OUTPUT 两个 hook 点拦截请求，然后跳转到自定义的 KUBE-SERVICES chain；
KUBE-SERVICES chain 执行真正的 Service 匹配，依据协议类型、目的 IP 和目的端口号。当匹配到某个 Service 后，就会跳转到专门针对这个 Service 创建的 chain，命名格式为 KUBE-SVC-<Service>。
KUBE-SVC-<Service> chain 根据概率选择某个后端 Pod 然后将请求转发过去。这其实是一种穷人的负载均衡器 —— 基于 iptables。选中某个 Pod 后，会跳转到这个 Pod 相关的一条 iptables chain KUBE-SEP-<POD>。
KUBE-SEP-<POD> chain 会执行 DNAT，将 VIP 换成 PodIP。

译注：以上解释并不是非常详细和直观，因为这不是本文重点。想更深入地理解基于 iptables 的实现，可参考网上其他一些文章，例如下面这张图所出自的博客《 Kubernetes Networking Demystified: A Brief Guide 》。

YzYFfme.png!mobile

NodePort Service

这种类型的 Service 也能被宿主机和 Pod 访问，但与 ClusterIP 不同的是，它还能被集群外的服务访问。

External node IP + port in NodePort range to any endpoint (pod), e.g. 10.0.0.1:31000
Enables access from outside

实现上，kube-apiserver 会从预留的端口范围内分配一个端口给 Service，然后每个宿主机上的 kube-proxy 都会创建以下规则：

-t nat -A {PREROUTING, OUTPUT} -m conntrack --ctstate NEW -j KUBE-SERVICES



-A KUBE-SERVICES ! -s 1.1.0.0/16 -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-MARK-MASQ

-A KUBE-SERVICES -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-NGINX

# 如果前面两条都没匹配到（说明不是 ClusterIP service 流量），并且 dst 是 LOCAL，跳转到 KUBE-NODEPORTS

-A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS



-A KUBE-NODEPORTS -p tcp -m tcp --dport 31000 -j KUBE-MARK-MASQ

-A KUBE-NODEPORTS -p tcp -m tcp --dport 31000 -j KUBE-SVC-NGINX



-A KUBE-SVC-NGINX -m statistic --mode random --probability 0.50 -j KUBE-SEP-NGINX1

-A KUBE-SVC-NGINX -j KUBE-SEP-NGINX2

前面几步和 ClusterIP Service 一样；如果没匹配到 ClusterIP 规则，则跳转到 KUBE-NODEPORTS chain。
KUBE-NODEPORTS chain 里做 Service 匹配，但这次只匹配协议类型和目的端口号。
匹配成功后，转到对应的 KUBE-SVC-<Service> chain，后面的过程跟 ClusterIP 是一样的。

小结

以上可以看到，每个 Service 会对应多条 iptables 规则。

Service 数量不断增长时，iptables 规则的数量增长会更快。而且，每个包都需要遍历这些规则，直到最终匹配到一条相应的规则。如果不幸匹配到最后一条规则才命中，那相比其他流量，这些包就会有很高的延迟。

有了这些背景知识，我们来看如何用 BPF/Cilium 来替换掉 kube-proxy，也可以说是重新实现 kube-proxy 的逻辑。

用 Cilium/BPF 替换 kube-proxy

我们从 Cilium 早起版本开始，已经逐步用 BPF 实现 Service 功能，但其中仍然有些地方需要用到 iptables。在这一时期，每台 Node 上会同时运行 cilium-agent 和 kube-proxy。

到了 Cilium 1.6，我们已经能完全基于 BPF 实现，不再依赖 iptables，也不再需要 kube-proxy。

iq2IZjZ.png!mobile

这里有一些实现上的考虑：相比于在 TC ingress 层做 Service 转换，我们优先利用 cgroupv2 hooks，在 socket BPF 层直接做这种转换（需要高版本内核支持，如果不支持则 fallback 回 TC ingress 方式）。

ClusterIP Service

对于 ClusterIP，我们在 BPF 里拦截 socket 的 connect 和 send 系统调用；这些 BPF 执行时，协议层还没开始执行（这些系统调用 handlers）。

Attach on the cgroupv2 root mount BPF_PROG_TYPE_CGROUP_SOCK_ADDR
BPF_CGROUP_INET{4,6}_CONNECT - TCP, connected UDP

TCP & connected UDP

对于 TCP 和 connected UDP 场景，执行的是下面一段逻辑：

int sock4_xlate(struct bpf_sock_addr *ctx) {

struct lb4_svc_key key = { .dip = ctx->user_ip4, .dport = ctx->user_port };

svc = lb4_lookup_svc(&key)

    if (svc) {

        ctx->user_ip4 = svc->endpoint_addr;

        ctx->user_port = svc->endpoint_port;

    }

return 1;

}

所做的事情：在 BPF map 中查找 Service，然后做地址转换。但这里的重点是（相比于 TC ingress BPF 实现）：

不经过连接跟踪（conntrack）模块，也不需要修改包头（实际上这时候还没有包），也不再 mangle 包。这也意味着，不需要重新计算包的 checksum。
对于 TCP 和 connected UDP，负载均衡的开销是一次性的，只需要在 socket 建立时做一次转换，后面都不需要了，不存在包级别的转换。
这种方式是对宿主机 netns 上的 socket 和 pod netns 内的 socket 都是适用的。

某些 UDP 应用：存在的问题及解决方式

但这种方式对某些 UDP 应用是不适用的，因为这些 UDP 应用会检查包的源地址，以及会调用 recvmsg 系统调用。

针对这个问题，我们引入了新的 BPF attach 类型：

BPF_CGROUP_UDP4_RECVMSG
BPF_CGROUP_UDP6_RECVMSG

另外还引入了用于 NAT 的 UDP map、rev-NAT map：

BPF rev NAT map

Cookie   EndpointIP  Port => ServiceID  IP       Port

-----------------------------------------------------

42       1.1.1.1     80   => 1          3.3.3.30 80

通过 bpf_get_socket_cookie() 创建 socket cookie。除了 Service 访问方式，还会有一些客户端通过 PodIP 直连的方式建立 UDP 连接， cookie 就是为了防止对这些类型的流量做 rev-NAT。
在 connect(2) 和 sendmsg(2) 时更新 map。
在 recvmsg(2) 时做 rev-NAT。

NodePort Service

NodePort 会更复杂一些，我们先从最简单的场景看起。

后端 Pod 在本节点

f6ryMfB.png!mobile

后端 Pod 在本节点时，只需要在宿主机的网络设备上 attach 一段 tc ingress bpf 程序，这段程序做的事情：

Service 查找
DNAT
redirect 到容器的 lxc0

对于应答包，lxc0 负责 rev-NAT，FIB 查找（因为我们需要设置 L2 地址，否则会被 drop），然后将其 redirect 回客户端。

后端 Pod 在其他节点

后端 Pod 在其他节点时，会复杂一些，因为要转发到其他节点。这种情况下，需要在 BPF 做 SNAT，否则 Pod 会直接回包给客户端，而由于不同 Node 之间没有做连接跟踪（ conntrack）同步，因此直接回给客户端的包出 Pod 后就会被 drop 掉。

所以需要在当前节点做一次 SNAT（src_ip 从原来的 ClientIP 替换为 NodeIP），让回包也经过当前节点，然后在这里再做 rev-SNAT（dst_ip 从原来的 NodeIP 替换为 ClientIP）。

具体来说，在 TC ingress 插入一段 BPF 代码，然后依次执行：Service 查找、DNAT、选择合适的 egress interface、SNAT、FIB lookup，最后发送给相应的 Node。

q2Ebaq.png!mobile

反向路径是类似的，也是回到这个 Node，TC ingress BPF 先执行 rev-SNAT，然后 rev-DNAT，FIB lookup，最后再发送回客户端，

JNVrui.png!mobile

现在跨宿主机转发是 SNAT 模式，但将来我们打算支持 DSR 模式（译注，Cilium 1.8+ 已经支持了）。DSR 的好处是 backend pods 直接将包回给客户端，回包不再经过当前节点转发。

另外，现在 Service 的处理是在 TC ingress 做的，这些逻辑其实也能够在 XDP 层实现，那将会是另一件激动人心的事情（译注，Cilium 1.8+ 已经支持了，性能大幅提升）。

当前基于 BPF 的 SNAT 实现中，用一个 LRU BPF map 存放 Service 和 backend pods 的映射信息。

需要说明的是，SNAT 除了替换 src_ip，还可能会替换 src_port：不同客户端的 src_port 可能是相同的，如果只替换 src_ip，不同客户端的应答包在反向转换时就会失败。因此这种情况下需要做 src_port 转换。现在的做法是，先进行哈希，如果哈希失败，就调用 prandom() 随机选择一个端口。

此外，我们还需要跟踪宿主机上的流（local flows）信息，因此在 Cilium 里基于 BPF 实现了一个连接跟踪器（connection tracker），它会监听宿主机的主物理网络设备（ main physical device）；我们也会对宿主机上的应用执行 NAT，Pod 流量 NAT 之后使用的是宿主机的 src_port，而宿主机上的应用使用的也是同一个 src_port 空间，它们可能会有冲突，因此需要在这里处理。

这就是 NodePort Service 类型的流量到达一台节点后，我们在 BPF 所做的事情。

Client pods 和 backend pods 在同一节点

另外一种情况是：本机上的 Pod 访问某个 NodePort Service，而且 backend pods 也在本机。

这种情况下，流量会从 loopback 口转发到 backend pods，中间会经历路由和转发过程，整个过程对应用是透明的 —— 我们可以在应用无感知的情况下，修改二者之间的通信方式，只要流量能被双方正确地接受就行。因此，我们在这里使用了 ClusterIP，并对其进行了一点扩展，只要连接的 Service 是 loopback 地址或者其他 local 地址，它都能正确地转发到本机 pods。

另外，比较好的一点是，这种实现方式是基于 cgroups 的，因此独立于 netns。这意味着我们不需要进入到每个 pod 的 netns 来做这种转换。

emI3Mz.png!mobile

Service 规则的规模及请求延迟对比

有了以上功能，基本上就可以避免 kube-proxy 那样 per-service 的 iptables 规则了，每个节点上只留下了少数几条由 Kubernetes 自己创建的 iptables 规则：

$ iptables-save | grep ‘\-A KUBE’ | wc -l:

- With kube-proxy: 25401

- With BPF: 4

在将来，我们有希望连这几条规则也不需要，完全绕开 Netfilter 框架（译注：新版本已经做到了）。

此外，我们做了一些初步的基准测试，如下图所示：

YrmymmF.png!mobile

可以看到，随着 Service 数量从 1 增加到 2000+，kube-proxy/iptables 的请求延迟增加了将近一倍，而 Cilium/eBPF 的延迟几乎没有任何增加。

Cilium 上手：用 kubeadm 搭建体验环境

有兴趣尝试 Cilium，可以参考下面的快速安装命令：

$ kubeadm init --pod-network-cidr=10.217.0.0/16 --skip-phases=addon/kube-proxy

$ kubeadm join [...]

$ helm template cilium \

     --namespace kube-system --set global.nodePort.enabled=true \

     --set global.k8sServiceHost=$API_SERVER_IP \

     --set global.k8sServicePort=$API_SERVER_PORT \

     --set global.tag=v1.6.1 > cilium.yaml

     kubectl apply -f cilium.yaml

扫描下方二维码，关注公众号『分布式实验室』，回复『201204』获取演讲PPT。

3UJnyee.jpg!mobile

译文链接： http://arthurchiao.art/blog/ci ... f-zh/

Kubernetes Service 类型及默认基于 kube-proxy 的实现

ClusterIP Service

NodePort Service

小结

用 Cilium/BPF 替换 kube-proxy

ClusterIP Service

NodePort Service

Service 规则的规模及请求延迟对比

相关的 Cilium/BPF 优化

BPF UDP recvmsg() hook

全局唯一 socket cookie

维护邻居表

LRU BPF callback on entry eviction

LRU BPF eviction zones

BPF 原子操作

BPF getpeername hook

绕过内核最大 BPF 指令数的限制

Cilium 上手：用 kubeadm 搭建体验环境

Recommend

聊聊golang的zap的NewProduction

“财富三角”：掌握最“经典”的致富方式

罗永浩关联直播交易案遭“问停” 尚纬股份终止跨界收购直播公司

奇客新西兰联合利华试行四天工作制

奇客中国科学家报告在量子计算上取得突破

奇客 Scott Aaronson 评价中国的量子计算成就

奇客 Linux 基金会年度报告是在 Mac 上制作的

奇客日本隼鸟 2 号准备将样本送回地球

微服务太难了, 学不会...

耗时五年，一位美国摇滚巨星自学成为程序员

About Joyk