上一篇二哥借助一张广角图聊了下数据中心、可用区、机架、物理机、VM、Pod之间的宏观关系。我们也确实可以看到，如今IT正在往虚拟化这个方向狂奔，十多年前，我们还在为以VM为代表的云计算机技术兴奋不已，如今大家的注意力已经完全被容器化吸引。
一方面从虚拟机的出现，到如今的容器化，虚拟的粒度越来越小，另一方面，从物理CPU、内存和存储虚拟化到网络的虚拟化，虚拟化的维度也越来越广。以网络虚拟化为例，在90年代，提到networking，它还仅代表物理的网线、拨号猫和一大堆二层三层的网络设备，而如今它可以代表SDN，Open vSwitch，bridge。
这一篇我们聊聊微距，我们重点看业界是如何利用虚拟化来实现容器网络的Underlay模式的。
广角回顾
图 1：广角大图
广角部分的详细内容请参考推文："广角-聊聊Underlay"。
Network namespace
Network namespace的概念不复杂，但二哥觉得越是简单的东西，有的时候我们越容易忽略它的内涵。
一个 Linux 容器能看见的“网络栈”，实际上是被隔离在它自己的 Network namespace 当中的，Network namespace用来隔离包括网卡（Network Interface）、回环设备（Loopback Device）、网络栈、IP地址、端口等等在内的网络资源。对于一个进程来说，这些要素，其实就构成了它发起和响应网络请求的基本环境。
所谓“网络栈（Network stack）”，包括了：路由表（Routing Table）， network filter，iptables 规则等。它的特点是由可配置的数据组成。
另外还有一个栈也会被经常提起：TCP/IP协议栈。我们可以将TCP/IP栈看成是程序的代码部分，而网络栈看成是程序的数据部分。很显然TCP/IP栈应该是被这个OS上所有人共享的，无论是进程还是容器，甚至是基于qemu-kvm的虚拟机都共享着宿主机的协议栈，但网络栈却是各自独享的。
注意：这个说法不是特别准确，目的是为了让大家可以区分网络栈和TCP/IP栈。
图 2：root network namespace和Pod network namespace对比
图2将Node上初始的Network namespace命名为root。不要纠结这个词对不对，你懂我的意思就行。正常情况下，在这个VM上跑的非容器进程都是在Root network namespace里的。
这张图展示了一个概念：一台VM上会存在Root network namespace和多个Pod network namespace。嗯，我好像说了一句废话。
现在思考一个问题：Pod里面的outgoing traffic离开了Pod后，它和root network namespace会不会相遇？
答案是：可能。其实这取决于流量从Pod里的eth0离开后是经过Root Network namespace还是与之直接擦肩而过，而这一切都由容器网络的具体实现技术决定。下面是三种典型的实现技术。
veth bridge
这种实现方式，我们称之为Overlay模式，如图1可用区B中容器网络所示。如果使用的是veth bridge模式，那么traffic离开Pod后，首先会出现在veth的另一端，而另一端是插在bridge上面的，这也就意味着流量直接进入了bridge。
如果数据包的目的MAC地址为bridge本身，并且网桥设置了IP地址的话，那bridge认为它收到的数据包应该要发往创建网桥的那台主机，在我们这个示例中，主机就是VM。于是这个数据包将不会被转发到网桥上的任何设备，而是直接交给VM的上层（三层）协议栈去处理。
这个过程所带来的效果是traffic从一个子网（容器所在的网络）离开，进入了另外一个子网（VM所在的网络），这其实也就模拟了traffic通过物理交换机的网关离开局域网的过程。
在Pod内将网关设为bridge的IP地址，Pod的协议栈会将网络包的dest MAC设置为bridge本身的MAC，也即下一跳MAC设为bridge。 网关是一个颇能迷惑新手的概念，实际上网关IP在网络通信过程中的所有traffic中都不会出现，但它不可或缺，它的作用是为了给traffic离开子网时指明下一跳MAC地址。
可以看到这种情况下，流出Pod的traffic进入了Root network namespace。因为VTEP的存在以及流量需要穿越Root network namespace，与主机间通信效率相比，这里出现了20%-30%的性能损耗。
veth root network namespace
这种实现方式，我们称之为主机（Node）间路由模式，如图1可用区C中容器网络所示。和可用区B相比，它也用到了veth，但因为没有使用bridge，vetch一端插在了Pod network namespace中，另一端直接插在了Root network namespace里。当traffic离开Pod并出现在veth另一端时，对于Root network namespace而言，它认为是它里面的一个网卡收到了ingress traffic。在Flannel host-gw，Calico BGP的实现中，Pod traffic需要经过Node的二层和三层的处理。
可以看到这种情况下，流出Pod的traffic也进入了Root network namespace。但与前一种模式相比，省去了VTEP这个解/封装环节，总性能损耗因此下降了很多，大概有10%左右。
multi-NIC热插拔
这种实现方式，我们称之为Underlay模式，如图1中可用区A容器网络所示。英文是：multi-NIC hot swapping。它有两个关键的概念：multi-NIC（多网卡）和热插拔，合起来表示通过虚拟化的方式，在VM里热插拔多个网卡。在机器上使用多个网卡不是特别的事情，但加上了多个关键词就意味着完全不同的使用场景了：VM，热插拔，多网卡。下文微距部分，我们可以看到这三个关键词是如何催化出神奇的魔力的。
微距看Pod如何翻身为一等公民
微距可以尽可能地放大被摄物体，查看细节。我们来把可用区A放大看看。
图 3：容器网络Underlay模式微距图
和可用区B、C最大的不同在于，在可用区A里面，Pod没有使用veth。咋一看这有点奇怪，没有veth的话，那么Pod里的traffic该如何离开容器网络又该如何路由呢？
在回答这个问题前，让我们先来看下图2。那张图其实在强调一个概念：root network namespace和Pod network namespace它们之间是相互独立的，平行的世界。让我们再复习下network namespace所隔离的内容：网卡、回环设备、网络栈、IP地址、端口等等。
这就表示：隔离特性使得流经这些namespace里，各自网络设备上面的流量是相互独立、平行的，尤其重要的是Pod里的流量进出这台虚拟机的时候，root network namespace无法感知到，所以在VM上对iptables、路由等设置对进出Pod的流量不起任何作用。traffic离开Pod和VM里的进程产生的traffic离开VM一样，都是离开各自的network namespace。
为了强调这样的平行关系，我在图3里画了两个蓝色的箭头，它们的出发点分别是VM和Pod，终点是穿过Open vSwitch的远方。traffic从各自的network namespace离开，互不见面，互不问候，互不干扰。
在这种模式下，可以看到这样的转变使得Pod摇身变成了和VM一样的一等公民。而在可用区B和C模式下，Pod还是要看VM的脸色才能传输数据的。
这个非常重要的网络隔离特性为Underlay模式提供了技术基础。有了技术，有了蓝图还不行，得有砖头才能盖成房子。这不，multi-NIC热插拔来了。
我们知道在物理机上，受制于PCIe插槽的限制，一台机器可以允许插入的网卡数量是有限的，而网卡虚拟化的到来则突破了这个限制，只要内存允许，可以创建无限个虚拟网卡。但可以建虚拟网卡还只是第一步，还得把这些虚拟网卡动态插入到协议栈，且协议栈还能认得它们，不然创建出来的虚拟网卡就成了摆设了。如今，在虚拟化浪潮下，这都成为了现实，这为Underlay模式的出现提供了实现基础。
当CNI得知K8s会在该Node上创建一个新的Pod时，它会将手中已有的（一般会提前创建虚拟网卡）网卡插入到Pod的network namespace，并给它配置IP地址，路由等信息，这些信息是与云平台IaaS的网络服务强相关的，实际上无论是阿里云还是AWS，都提供了OpenAPI，以供CNI创建虚拟网卡并获取这些信息。
当你耐着性子听二哥啰嗦到这个地方的时候，也许会明白所谓的一等公民意味着什么：它意味着Pod和VM一起平等分享云平台服务商所提供的网络基础设施如SDN，VPC等，也因此获得和VM一样的网络传输性能。
其实不只是性能传输的平等性，我们可以看到Pod和VM都连接到了Open vSwitch上，这就使得我们可以通过OpenFlow在SDN控制平面来统一控制Pod和VM，如流量控制，流量监控，VLAN层级的隔离。
周志明老师在《凤凰架构》一书中说：对于真正的大型数据中心、大型系统，Underlay 模式才是最有发展潜力的网络模式。这种方案能够最大限度地利用硬件的能力，往往有着最优秀的性能表现。但也是由于它直接依赖于硬件与底层网络环境，必须根据软、硬件情况来进行部署，难以做到 Overlay 网络那样开箱即用的灵活性。
