pip在上期，我们讲到，对于私有化部署的容器平台，传统开源的calico,flannel等基于iptables/ipvs的容器插件无法同时满足以下几点
而eBPF的出现，让开发者能够实现非侵入式修改内核数据包处理流程，在不修改内核代码的情况下，灵活地自定义转发流程，如增加特定标志位等。Cilium就是基于eBPF进行开发的容器网络插件。
上图为Cilium的广告。它实际的架构如下图：
当容器运行时(如Containerd)在工作节点上创建容器时，kubelet会调用cilium cni，并由cilium agent执行。cilium agent会调用内核中BPF模块的API，加载cilium的eBPF代码，让eBPF模块拦截容器APP的网络数据收发，进行包封装/解封装，最终从工作节点的网卡(NIC)发出。
如果Kubernetes的工作节点为虚拟机，那么，Cilium推荐大家使用overlay模式，也就是隧道封装模式。它的工作原理如下图：
如图，cilium agent工作在Kubernetes的工作节点上，两个Pod的IP地址分别为172.17.10.161和172.17.10.162。Cilium Agent控制内核中eBPF模块将Pod之间的网络交互进行封装，隧道两端的IP就是Kubernetes工作节点的IP地址 172.16.112.10和172.16.112.20。
我们前面提到，flannel的一个弊端就是，VXLAN封装的开销较大。那么，为什么flannel不采用其他效能更高的封装方式呢？这是因为，flannel实际上只是调用了Linux内核的VXLAN封装功能，也就是将数据包通过tun0发送，并将tun0设定为VXLAN封装。由于flannel并没有修改内核代码，也就无法改变内核的数据处理方式，没有办法使用更优的封装方式。
Cilium对此做了改进。以流行的商业版本容器平台TCS (Tencent Cloud-native Suite)为例，Cilium采用ipip封装。ipip封装指的是将IP业务数据包封装在外层的IP隧道数据包内，如下图所示：
也就是仅仅增加了20字节的包头，比GRE、NVGRE、VXLAN等封装方式的开销都要小。
cilium的另一种工作模式适合物理服务器作为容器工作节点，且网络节点能够直接路由的场景，与calico类似：
Cilium会使能每个工作节点上的路由模块，如Kubernetes自带的Kube-router，与BGP RR进行交互。同时，三层网络节点也作为BGP RR的Client。但是，Kube-router在高可用方面有一些缺陷。它不支持BFD和ECMP，不能实现BGP连接的高可用和快速切换，用于生产核心系统是存在缺陷的。
针对这个缺陷，工程师们开发的取代方案是吸取Calico的长处用BIRD套件取代Kube-Router和RR。BIRD是一个开源的BGP路由套件，由BGP路由Client和RR组成。在集群内部署了RR节点，并在每个工作节点上部署Client，就搞定了生产级别的BGP高可用。
“他山之石，可以攻玉”。
不仅仅是Cilium的演进从这个古老的哲理中收益，Kubernetes网络还吸取了很多开源组件，并帮助其演进到了生产级别。请看下期分解。
