计算驱动下的容器 络及数据包过滤

一、背景

过去二十多年 络发生了很多的变化。数据中心物理拓扑方面，由接入-汇聚-核心三级 络架构演进到Spine-Leaf两级架构；软件方面，出现了各种各样的 络虚拟化，例如软件实现的虚拟 桥、虚拟机交换机、虚拟路由器、软件overlay 络等。

很多新的概念和模型，例如软件定义 络（SDN）的转发与控制分离思想，实现上可以像Google一样基于OpenFlow，可以是后来用的比较多的BGPEVPN；另外还有Spine-Leaf中的分布式 关概念；还有大二层 络与纯三层路由 络等等概念。

具体一些的话如bare metal集群可能会采用DHCP加扁平二层（flatL2） 络；虚拟机应用比较有代表性的OpenStack平台，采用的是Neutron+OVS大二层 络；Docker内置的典型 络模型是宿主机内的bridge加出宿主机的SNAT，并定义了CNM 络模型；Kubernetes定义了CNI 络规范，符合这个规范的实现有我们现在所熟悉的Flannel、Calico、Cilium等等。

这么多的 络方案，或者说 络架构和解决方案在不断演进。这种不断增长的计算规模来我们如何高效地进行数据的转发、跟踪、安全分析等。

二、eBPF的应用

Linux 内核一直是实现监控/可观测性、 络和安全功能的理想地方。不过很多情况下这并非易事，因为这些工作需要修改内核源码或加载内核模块， 最终实现形式是在已有的层层抽象之上叠加新的抽象。eBPF 是一项革命性技术，它能在内核中运行沙箱程序（sandbox programs）， 而无需修改内核源码或者加载内核模块。

将 Linux 内核变成可编程之后，就能基于现有的（而非增加新的）抽象层来打造更加智能、 功能更加丰富的基础设施软件，而不会增加系统的复杂度，也不会牺牲执行效率和安全性。

eBPF 催生了一种全新的软件开发方式。基于这种方式，我们不仅能对内核行为进行 编程，甚至还能编写跨多个子系统的处理逻辑，而传统上这些子系统是完全独立、 无法用一套逻辑来处理的。

1、安全

观测和理解所有的系统调用的能力，以及在 packet 层和 socket 层次审视所有的 络操作的能力， 这两者相结合，为系统安全提供了革命性的新方法。以前，系统调用过滤、 络层过滤和进程上下文跟踪是在完全独立的系统中完成的；eBPF 的出现统一了可观测性和各层面的控制能力，使我们有更加丰富的上下文和更精细的控制能力， 因而能创建更加安全的系统。

2、 络

eBPF 的两大特色 —— 可编程和高性能 —— 使它能满足所有的 络处理需求。可编程意味着无需离开内核中的包处理上下文，就能添加额外的协议解析器或任何转发逻辑， 以满足不断变化的需求。高性能的 JIT 编译器使 eBPF 程序能达到几乎与原生编译的内核态代码一样的执行性能。

3、跟踪 & 性能分析

eBPF 程序能够加载到 trace points、内核及用户空间应用程序中的 probe points， 这种能力使我们对应用程序的运行时行为（runtime behavior）和系统本身 （system itself）提供了史无前例的可观测性。应用端和系统端的这种观测能力相结合， 能在排查系统性能问题时提供强大的能力和独特的信息。BPF 使用了很多高级数据结构， 因此能非常高效地导出有意义的可观测数据，而不是像很多同类系统一样导出海量的原始采样数据。

4、观测 & 监控

相比于操作系统提供的静态计数器（counters、gauges），eBPF 能在内核中收集和聚合自定义 metric， 并能从不同数据源来生成可观测数据。这既扩展了可观测性的深度，也显著减少了整体系统开销， 因为现在可以选择只收集需要的数据，并且后者是直方图或类似的格式，而非原始采样数据。

三、容器 络

容器也被称为轻量级虚拟机，所以它的很多 络需求与虚拟机类似，但部署密度高了一个数量级。典型的容器平台有Mesos、Kubernetes等。

1、二层 络模型

在传统二层模型的基础上，将虚拟机换成容器，如下图所示：

如果没有一些很特殊的业务需求，只是单纯基于已有二层 络实现这样一套容器方案，其技术难度和开发量都不是很大，例如，如果要将Kubernetes接入OpenStackNeutron 络，开发一个针对Neutron+OVS的CNI插件就可以了。

但前面提到，这种globalIPAM+centralgateway方案中，核心交换机需要记录每个实例的IP/MAC信息，再考虑到容器的部署密度，可以预见的是，交换机硬件表项将撑不住。

在实际的应用中，除了硬件交换机表现出瓶颈，在软件上，其实globalIPAM也已经无法在性能上满足容器频繁的漂移、创建、销毁的需求了。所以大二层 络方案在软件和硬件上都已经陷入了困境。

2、避免 络瓶颈

如何在物理 络上支撑几十万以上的容器？显然，最重要的一点就是不能让核心交换机记录所有的容器的信息 IP 信息。

主流的设计方式有：

核心交换机就只需要记录node本身的IP和它管理的 段，表中重新回到与宿主机数量同一量级，而与容器的数量没有直接关系。IPAM从中心式变成了分散式，性能瓶颈也解决了。

四、云原生 络

最近两年较为流行的 络方案为：Cilium+BGP。Cilium的核心基于eBPF，这是4.8内核引入的一项革命性技术：它使得内核变得可编程。这里可编程的意思是，以前要改变内核行为，需要修改内核代码、编译调试、重新打镜像、安装运行等等，而且还要维护自己的内核分支，现在可能写几行eBPF代码然后动态加载到内核就能实现同样的效果。

Cilium的组件如上图所示，主要包括：

eBPF目前主要用在两个方向：动态跟踪（tracing）和 络（networking）。有了eBPF/XDP之后，我们可以看到数据平面处理（dataplaneprocessing）有一个趋势：

五、总结

计算模型驱动下的 络发展是复杂的，涉及到很多因素，最终都是业务需求和 络层的反映，在计算规模的角度上如何平衡 络、稳定、安全、效率等。