云计算网络技术内幕 (21) 未来的希望

在上一期，我们针对私有化部署的容器平台在网络实现方面的困难进行了分析：

1. Node之间的网络是未知的，有可能是物理服务器直接联网，有可能是虚拟机通过VPC互联，也可以是物理服务器以裸金属方式接入VPC；

2. 无法保证Node之间网络各个节点通过BGP学习路由；

3. 尽量减少隧道方式的开销；

4. 需要提供network policy的数据包过滤功能；

这些问题的版本答案是：基于Linux的eBPF开发的Cilium。

想了解什么是Cilium，首先要理解什么是eBPF。eBPF是extened Berkeley Packet Filter的缩写。eBPF 的概念源自于 Berkeley Packet Filter（BPF），后者是由贝尔实验室开发的一种网络过滤器，可以捕获和过滤网络数据包。

我们知道，Linux的网络功能在内核中实现。为了控制内核对数据包的一些处理，Linux增加了iptables的功能，但iptables只能简单地实现数据包的过滤和转发动作，无法实现对数据包更深入的解析和修改。eBPF就是为了解决这一矛盾而在2014年的Linux内核3.18版本中引入的。

eBPF实际上是Linux内核中的一个模拟机(Emulated Machine)，可以支持eBPF定义的类RISC指令(Emulated Machine和Virtual Machine的差异请大家自行查询计算机理论相关资料)，其指令用于对数据包进行匹配和操作。特别地，eBPF Emulated Machine特意被设计为非图灵完备的，如仅支持有界循环指令，避免内核挂死。

eBPF指令的范例，我们可以参照这里：

https://github.com/torvalds/linux/blob/v4.20/samples/bpf/sock_example.c

从47行开始的BPF_MOV64_REG等宏，最终会被转换为eBPF Emulated Machine的二进制字节码，对数据包进行操作。当然，如果用eBPF指令进行eBPF开发，其难度等同于使用汇编语言开发应用。因此，eBPF团队也为开发者提供了高级语言工具，如采用LLVM等编译器将类似C语言的代码编译为eBPF汇编(字节码)。

如图，用户可以在用户态进行eBPF编程，使用LLVM等工具生成eBPF的字节码。内核中的eBPF加载eBPF字节码后，就可以干预注册在eBPF模块上的内核回调函数的行为。

Cilium就是利用eBPF开发的Kubernetes网络插件。

我们提到，eBPF是Linux可以直接对内核网络栈进行编程的一种接口。而Kubernetes网络实现本质上就是让来自不同namespace进程的数据包，在内核网络栈模块中得以正确处理，如通过work node上正确的网络端口发送，发送前需要在ip数据包头前增加正确的IP地址，或将IP数据包封装到特定的隧道中。

熟悉Kubernetes的同学会发现，实际上在Cilium出现之前，Kubernetes的各类插件都可以通过Kube-proxy实现数据平面的操作。那么，开发基于eBPF的容器网络插件的动力是什么呢？难道只是基于创新吗？

原来，Kube-proxy实际上并不是一个真正的代理服务器或网络转发模块。它只是在K8S work node上驻留，并且根据来自API Server的指令去刷新iptables，而实质的数据平面转发工作还是由iptables来实现。Iptables作为数据平面转发组件，有着一个致命的缺陷：线性查表。

Iptables的数据平面工作流程如上图所示。所谓的线性查表，指的是在input, output和forward三个环节，在filter流程中，需要逐条匹配规则，如果有100条规则就需要匹配100次。显然，转发一个数据包需要CPU这么多次操作，是非常不优雅而且严重消耗CPU资源的。

kube-proxy另一种工作方式是ipvs。ipvs也是linux内核中的模块，可以实现类似iptables的功能。ipvs最大的改进是使用了哈希表查找，其时间复杂度为O(log(N))，因此对CPU占用大大降低。在Kubernetes 1.12以后，Kube-proxy也可以使用ipvs作为转发面。但是，ipvs也属于内核态，如果用户期望对数据包进行较为灵活的修改和封装，就需要修改内核，这对原有系统的冲击太大，是不现实的。

在这样的背景下，利用eBPF实现的Cilium就成为了容器网络未来的希望。