3. overlay network - Overlay Network
Overlay network (overlay network) is a TCP data packaging technology and communications routing forwarding network packets inside another. Overlay network is not required by default, but they are very useful in certain scenarios. For example, when we do not have enough space for IP, or network can not handle the additional route, or when certain additional management features we need Overlay provide. A common scenario is when a cloud provider's routing number routing table can handle is limited, such as support for AWS routing tables up to 50 routes that they will not affect network performance. So if we have more than 50 Kubernetes nodes, AWS routing table is not enough. In this case, use Overlay network will help us.
Essentially, Overlay layer packet is then encapsulated in a packet on the local network node across. You may not want to use Overlay network, because it will bring delay and cost caused by the complexity of all messages encapsulated and re-opened files. Usually this is not necessary, so we should know why we need it when using it.
Overlay network in order to understand the flow of traffic, we take Flannel an example, it is CoreOS an open source project. Flannel provide virtual network by assigning a subnet to each host mode for the container, which is based on Linux TUN / TAP, use UDP encapsulation IP packet to create overlay network, and with the etcd maintain the distribution network.
Route with the Node Table Kubernetes
(Pod-to-Pod for communications across a network node through Flannel Overlay)
Here we note that we have seen it before and facilities is the same, but adds a virtual Ethernet device in the root netns, called flannel0. It is a virtual extension of the network Virtual Extensible LAN (VXLAN) an implementation, but on Linux, it's just another network interface.
Pod1 from the POD 4 (at different nodes) to the packets similar to the following:
1. It netns pod1 by the network interface eth0 to leave, by vethxxx into the root netns.
2.然后被传到cbr0，cbr0通过发送ARP请求来找到目标地址。
3.数据封装
*a. 由于本节点上没有Pod拥有pod4的IP地址，因此网桥把数据包发送给了flannel0，因为节点的路由表上flannel0被配成了Pod网段的目标地址。
*b. flanneld daemon和Kubernetes apiserver或者底层的etcd通信，它知道所有的Pod IP，并且知道它们在哪个节点上。因此Flannel创建了Pod IP和Node IP之间的映射（在用户空间）。flannel0取到这个包，并在其上再用一个UDP包封装起来，该UDP包头部的源和目的IP分别被改成了对应节点的IP，然后发送这个新包到特定的VXLAN端口（通常是8472）。
Packet-in-packet encapsulation
（notice the packet is encapsulated from 3c to 6b in previous diagram）
尽管这个映射发生在用户空间，真实的封装以及数据的流动发生在内核空间，因此仍然是很快的
*c. 封装后的包通过eth0发送出去，因为它涉及了节点间的路由流量。
4.包带着节点IP信息作为源和目的地址离开本节点。
5.云提供商的路由表已经知道了如何在节点间发送报文，因此该报文被发送到目标地址node2。
6.数据解包
*a. 包到达node2的eth0网卡，由于目标端口是特定的VXLAN端口，内核将报文发送给了 flannel0。
*b. flannel0解封报文，并将其发送到 root 命名空间下。从这里开始，报文的路径和我们之前在Part 1 中看到的非Overlay网络就是一致的了。
*c. 由于IP forwarding开启着，内核按照路由表将报文转发给了cbr0。
7.网桥获取到了包，发送ARP请求，发现目标IP属于vethyyy。
8.包跨过管道对到达pod4
这就是Kubernetes中Overlay网络的工作方式，虽然不同的实现还是会有细微的差别。有个常见的误区是，当我们使用Kubernetes，我们就不得不使用Overlay网络。事实是，这完全依赖于特定场景。因此请确保在确实需要的场景下才使用。
4. 动态集群
由于Kubernetes（更通用的说法是分布式系统）天生具有不断变化的特性，因此它的Pod（以及Pod的IP）总是在改变。变化的原因可以是针对不可预测的Pod或节点崩溃而进行的滚动升级和扩展。这使得Pod IP不能直接用于通信。
我们看一下Kubernetes Service，它是一个虚拟IP，并伴随着一组Pod IP作为Endpoint（通过标签选择器识别）。它们充当虚拟负载均衡器，其IP保持不变，而后端Pod IP可能会不断变化。
Kubernetes service对象中的label选择器
整个虚拟IP的实现实际上是一组iptables（最新版本可以选择使用IPVS，但这是另一个讨论）规则，由Kubernetes组件kube-proxy管理。 这个名字现在实际上是误导性的。 它在v 1.0之前确实是一个代理，并且由于其实现是内核空间和用户空间之间的不断复制，它变得非常耗费资源并且速度较慢。 现在，它只是一个控制器，就像Kubernetes中的许多其它控制器一样，它watch api server的endpoint的更改并相应地更新iptables规则。
Iptables DNAT
有了这些iptables规则，每当数据包发往Service IP时，它就进行DNAT（DNAT=目标网络地址转换）操作，这意味着目标IP从Service IP更改为其中一个Endpoint - Pod IP - 由iptables随机选择。这可确保负载均匀分布在后端Pod中。
conntrack表中的5元组条目
当这个DNAT发生时，这个信息存储在conntrack中——Linux连接跟踪表（iptables规则5元组转译并完成存储：protocol，srcIP，srcPort，dstIP，dstPort）。 这样当请求回来时，它可以un-DNAT，这意味着将源IP从Pod IP更改为Service IP。 这样，客户端就不用关心后台如何处理数据包流。
因此通过使用Kubernetes Service，我们可以使用相同的端口而不会发生任何冲突（因为我们可以将端口重新映射到Endpoint）。 这使服务发现变得非常容易。 我们可以使用内部DNS并对服务主机名进行硬编码。 我们甚至可以使用Kubernetes提供的service主机和端口的环境变量来完成服务发现。
专家建议： 采取第二种方法，你可节省不必要的DNS调用，但是由于环境变量存在创建顺序的局限性（环境变量中不包含后来创建的服务），推荐使用DNS来进行服务名解析。
4.1 出站流量
到目前为止我们讨论的Kubernetes Service是在一个集群内工作。但是，在大多数实际情况中，应用程序需要访问一些外部api/website。
通常，节点可以同时具有私有IP和公共IP。对于互联网访问，这些公共和私有IP存在某种1：1的NAT，特别是在云环境中。
对于从节点到某些外部IP的普通通信，源IP从节点的专用IP更改为其出站数据包的公共IP，入站的响应数据包则刚好相反。但是，当Pod发出与外部IP的连接时，源IP是Pod IP，云提供商的NAT机制不知道该IP。因此它将丢弃具有除节点IP之外的源IP的数据包。
因此你可能也猜对了，我们将使用更多的iptables！这些规则也由kube-proxy添加，执行SNAT（源网络地址转换），即IP MASQUERADE（IP伪装）。它告诉内核使用此数据包发出的网络接口的IP，代替源Pod IP同时保留conntrack条目以进行反SNAT操作。
4.2 入站流量
到目前为止一切都很好。Pod可以互相交谈，也可以访问互联网。但我们仍然缺少关键部分 - 为用户请求流量提供服务。截至目前，有两种主要方法可以做到这一点：
* NodePort /云负载均衡器（L4 - IP和端口）
将服务类型设置为NodePort默认会为服务分配范围为30000-33000的nodePort。即使在特定节点上没有运行Pod，此nodePort也会在每个节点上打开。此NodePort上的入站流量将再次使用iptables发送到其中一个Pod（该Pod甚至可能在其它节点上！）。
云环境中的LoadBalancer服务类型将在所有节点之前创建云负载均衡器（例如ELB），命中相同的nodePort。
* Ingress（L7 - HTTP / TCP）
许多不同的工具，如Nginx，Traefik，HAProxy等，保留了http主机名/路径和各自后端的映射。通常这是基于负载均衡器和nodePort的流量入口点，其优点是我们可以有一个入口处理所有服务的入站流量，而不需要多个nodePort和负载均衡器。
4.3 网络策略
可以把它想象为Pod的安全组/ ACL。 NetworkPolicy规则允许/拒绝跨Pod的流量。确切的实现取决于网络层/CNI，但大多数只使用iptables。
结束语
目前为止就这样了。 在前面的部分中，我们研究了Kubernetes网络的基础以及overlay网络的工作原理。 现在我们知道Service抽象是如何在一个动态集群内起作用并使服务发现变得非常容易。我们还介绍了出站和入站流量的工作原理以及网络策略如何对集群内的安全性起作用。
参考文章
An illustrated guide to Kubernetes Networking - part1
An illustrated guide to Kubernetes Networking - part2
An illustrated guide to Kubernetes Networking - part3