3. 覆盖网络 - Overlay Network
覆盖网络(overlay network)是将TCP数据包装在另一种网络包里面进行路由转发和通信的技术。Overlay网络不是默认必须的，但是它们在特定场景下非常有用。比如当我们没有足够的IP空间，或者网络无法处理额外路由，抑或当我们需要Overlay提供的某些额外管理特性。一个常见的场景是当云提供商的路由表能处理的路由数是有限制时，例如AWS路由表最多支持50条路由才不至于影响网络性能。因此如果我们有超过50个Kubernetes节点，AWS路由表将不够。这种情况下，使用Overlay网络将帮到我们。
本质上来说，Overlay就是在跨节点的本地网络上的包中再封装一层包。你可能不想使用Overlay网络，因为它会带来由封装和解封所有报文引起的时延和复杂度开销。通常这是不必要的，因此我们应当在知道为什么我们需要它时才使用它。
为了理解Overlay网络中流量的流向，我们拿Flannel做例子，它是CoreOS 的一个开源项目。Flannel通过给每台宿主机分配一个子网的方式为容器提供虚拟网络，它基于Linux TUN/TAP，使用UDP封装IP包来创建overlay网络，并借助etcd维护网络的分配情况。
(通过Flannel Overlay网络进行跨节点的Pod-to-Pod通信)
这里我们注意到它和之前我们看到的设施是一样的，只是在root netns中新增了一个虚拟的以太网设备，称为flannel0。它是虚拟扩展网络Virtual Extensible LAN（VXLAN）的一种实现，但是在Linux上，它只是另一个网络接口。
从pod1到pod4（在不同节点）的数据包的流向类似如下：
1.它由pod1中netns的eth0网口离开，通过vethxxx进入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）。
（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可能会不断变化。
整个虚拟IP的实现实际上是一组iptables（最新版本可以选择使用IPVS，但这是另一个讨论）规则，由Kubernetes组件kube-proxy管理。 这个名字现在实际上是误导性的。 它在v 1.0之前确实是一个代理，并且由于其实现是内核空间和用户空间之间的不断复制，它变得非常耗费资源并且速度较慢。 现在，它只是一个控制器，就像Kubernetes中的许多其它控制器一样，它watch api server的endpoint的更改并相应地更新iptables规则。
有了这些iptables规则，每当数据包发往Service IP时，它就进行DNAT（DNAT=目标网络地址转换）操作，这意味着目标IP从Service IP更改为其中一个Endpoint - Pod IP - 由iptables随机选择。这可确保负载均匀分布在后端Pod中。
当这个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
