这是Kubernetes网络系列的第二篇文章，如果你还未读第一篇文章，我强烈建议回头去读第一篇文章。
在上一篇文章中我通过网络模型介绍了Kubernetes中同节点上的Pod、不同节点上的Pod相互通信的原理。同时我们发现linux网桥和路由表在Kubernetes网络模型中的起到的重要作用。
接下来我将通过讲解overlay networks的工作原理继续拓展Kubernetes网络模型的概念，我也希望你能理解不断变化的Pods是如何从Kubernets内部运行的应用中抽象出来的。
Overlay Networks
尽管默认情况下overlay networks并不是必须的，但是在特定的场景中它有很大的作用。比如当我们没有足够待分配的IP地址或者路由表不足以支撑集群的节点数量时或者当我们想使用Overlay Networks中的特殊性质时。其中最常见的例子是云服务厂商不能提供足够大的路由表存储集群节点的路由信息，如AWS的路由表在不影响网络性能的情况下最多可以处理50条集群节点间的路由信息，在这种情况下overlay networks将发挥很大的作用。
Overlay Networks本质是对跨节点间网络包的层层压缩。网络包在Overlay Networks中压缩与解压的耗时，将会增大网络的延迟和复杂度。因此我们并不常使用，如果你必须使用它，请务必知晓为什么使用它。
为了更好的理解网络包是如何在overlay networks中传递的流程，我将通过CoreOS开源的flannel网络模型作为讲解。
网络流程图与上一篇文章的很像，仔细看你会发现在root netns中多出了Virtual Extensible LAN（VXLAN），VXLAN本质上来说是Linux的网络接口。
网络包从Pod1到Pod4的流程图大致如下面所示：
- 网络包通过eth0流出Pod1经由vethxxxx进入root netns
- 网络到达网桥cbr0时，网桥做ARP请求试图寻找网络包的目的地址
- 在节点内并未发现pod4的IP地址，由于早已将Pod的IP地址区间加入路由表内，网桥将网络包发送到flannel设备上
- 后台驻留的flanneld程序存储着所有Pod的IP以及运行的节点IP地址的映射关系，并将这些关系告诉Kubernetes API Server和后台的etcd程序
flannel0网络设备在获取网络包后，将网络包包裹着额外的包头。这个包头改变源IP地址和目的IP地址以及对应的节点IP地址信息，最后将这些包发往vxlan独特的端口地址（通常是8472）。
即便映射关系在用户空间，网络包的压缩和解压以及数据流发生在Linux内核中，因此网络的传输还是非常迅速的。
- 节点的eth0设备涉及流量的转发，因此所有的网络包都是从这里转发出去的
- 网络包将源节点和目的节点宿主机对应的IP地址作为源IP地址和目的IP地址
- 云服务商提供的路由知道如何做节点间流量的转发，将网络包发往目的节点
- 网络包到达目的节点node2后，由于使用的是特殊的vxlan端口号，Linux内核将网络包发往flannel0上
- linux内核解压网络包后将网络包发往root network空间中
接下来的流程与上一篇文章中流程很接近了。
- Linux内核将网络包转发到cbr0网桥上
- 网桥收到网络包后，做ARP请求发现网络包的目的地址属于网络设备vethyyyy
- 最后网络到达pod4
以上即使跨节点的pipe-pair的全过程
尽管Overlay Networks的实现方式各有不同，上面的过程是Overlay Networks在Kubernetes中的大致流程。普遍存在一个误区Kubernetes必须要使用overkay网络，而真实的情况是要根据使用场景来判断是否使用Overlay Networks。
以上就是pipe-pair的全过程，在前一篇文章中我们学习了Kubernetes的网络基础。现在我们探讨了Overlay网络的工作原理，接下来我们将一起学习如何从Pod中抽象Service以及出栈和入栈网络的工作流。
文章翻译自An illustrated guide to Kubernetes Networking [Part 2],是略有删减
