01
**背景 **
在云原生相对成熟的今天，对于 Kubernetes 本身的能力需求，逐渐变得不那么迫切，因为常见的能力都已经成熟稳定了。但是在周边领域还处于不断发展的过程，特别是容器的网络方案，存储方案，安全领域等。
重点是网络方案， 举例来说，一个企业要想成功落地容器平台，首先要解决的问题就是网络方案的选型。选型的参考没有标准化。有根据易用性的；有根据规模的；有根据性能的；有根据应用亲和的 (固定 IP)，有根据企业内部网络要求的，有根据网络安全要求的，有根据稳定性的 (相对而言) ，有根据可运维性的，等等。
在选型的时候选型的条件大多数是组合条件，这些条件对容器的网络方案就提出了很多的挑战。不同的厂商或者开源项目都在构建不同场景下的网络方案。
从容器的网络发展路线来看，包括以下几个阶段：
- 基于 Linux bridge 以及基于 ovs 实现的 overlay 的网络。
- 基于 bgp/hostgw 等基于路由能力的网络。
- 基于 macvlan，ipvlan 等偏物理网络的 underlay 的网络。
- 基于 Kernel 的 eBPF 的技术实现的网络。
- 基于 dpdk/sriov/vpp/virtio-user/offload/af-xdp 实现的用户态的网络。
第一/二/三种网络的方案有一个共同的特性就是完全使用内核成熟的技术，以及对于 netfilter，也就是 iptables 的能力，就是拿来用就可以，不会考虑 bypass 它。
第四种的网络方案中也会用到 iptables，但是它的设计思想是尽量的 bypass netfilter/iptables，以及基于内核的 eBPF 技术实现网络设备之间 redirect 的方式 bypass netfilte，让网络数据处理的路径尽量的短，进而达到高性能的目的，不是说 eBPF 不稳定，而是想要实现更好的性能，对内核的 uapi 的依赖性比较高，往往要开发 feature，并合并到内核去，然后再使用，前三种方案使用的内核技术都是非常成熟的，不会有太多的功能会依赖开发新的内核特性。
第五种网络的方案的主要场景就是希望最快的网络，不同的实现方案，会有硬件的依赖，会有用户态协议栈的技术，内存网络加速的技术，有的方案还会对应用本身有侵入性，而且此方案也是相对最复杂的。
从技术路线来看，不难看出的是，对容器的网络方案的基本诉求就是要越来越快。
从功能的角度看和使用的角度看，基本是类似的，原因是使用的接口都是标准的 CNI 标准接口。
从发展的阶段看，理论上用户态的网络能力是最快的，因为 bypass 了 Kernel，但是也意味着对硬件和应用是有一定的要求的，技术的通用性稍微显得有点不太兼容。
其余 4 种方案都是基于内核技术，通用性比较好。方案没有好坏之分，适合自己的才是好的。那接下来就要看看谁的性能是比较好的。
本文不对所有的网络方案做分析，主要针对最近比较热门的基于 eBPF 实现的 Cilium 网络技术，做一些相关的技术分享。
02
**技术术语 **
为了更好的理解 Cilium 实现的能力，首先需要对一些常见的内核技术和网络技术的相关概念有一个初步的认识之后，会更好的帮助理解原理。以下整理一些技术术语，不是包含所有的，主要列出来一些主要的点。
- CNI： Kubernetes 的网络插件的接口规范的定义，主要能力是对接 Kubelet 完成容器网卡的创建，申请和设置 ip 地址，路由设置，网关设置。核心接口就是cmdAdd/cmdDel ，调用接口期间，会传递 Pod 相关的信息，特别是容器网卡的name，以及 Pod 的 network namespace 等信息。
- IPAM： 容器的网卡对应的 ip 分配就是由 IPAM 完成，从全称可以看出来，IP Address Management。这个组件是由 CNI 调用来完成为 Pod 申请 ip 地址。
- Vxlan： 用于在实现 overlay 网络中，跨主机通信的能力，基于封包和隧道的能力，实现 2 层虚拟网络。不同主机互相维护对端的隧道地址，通过主机的内核路由，实现数据包跨机器组建 overlay 网络。
- Network Policy： 用于定义 Kubernetes 中，容器访问控制，容器安全等能力的定义规范。可以实现能不能从容器出去，能不能访问某一个容器，能不能访问某一个服务的port 等等，包括 L3/L4/L7 以及自定义扩展的协议的安全能力。
- Linux Veth： Linux 提供的一种虚拟网络技术，可以实现跨 network namespace 通信能力。一端在主机网络空间，一端在容器的网络空间。
