kubenetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中，这在GCE（谷歌云服务器里）中里面是现成的网络模型，kubenetes假定这个网络已经存在,
而在私有云里搭建kubenetes集群，就不能假定这个网络已经存在了，我们需要自己实现这个网络假设，将不同节点上的Docker容器之间的互相访问先打通，然后运行kubenetes
先了解一下：
①同一个pod之间的多个容器怎么互相访问：通过共用的pause这个容器的网络站的IO，通过localhost方式可以访问
②各pod之间的通讯：通过Overlay Network
③Pod与service之间的通讯：通过各节点的Itables规则
Flannel是什么？
Flannel是CoreOS团队针对kubenetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
而且它还能在这些IP之间建立一个覆盖网络（ 就是Overlay Netwok），通过这个覆盖网络，将数据包原封不动的传递到目标容器内。
下图解析：
图上表示有两台物理机11和12 ，分别运行了2个Pod 。11主机对应的是Web app1和Web app2 两个Pod，2主机读音的是Web app3和Backend两个Pod，Backend是前端的
所以该结构就是 流量访问到Backend上，经过它自己的网关去处理把对应请求分配到对应的服务上（对应3个Web app），那么Web app1想要跟Backend通讯时，就要跨主机了，
Web app3想要跟Backend通讯就是同主机不同Pod之间的通讯了
首先，在真实的Node服务器上，我们会去安装一个Flanneld的守护进程，这个守护进程会去监听一个端口（这个端口就是用于后期转发数据包的一个服务端口），Flanneld一旦启动后，会开启一个网桥Flannel0，这个Flannel0专门收集Docker0转发出来的数据包，你可以理解Flannel0是一个勾子，然后Docker0会分配自己的IP到对应的Pod上。
如果是同一台主机的不同Pod之间访问，那么走的是Docker0的网桥，因为这两个Pod都是同一个网桥下的不同子IP而已。
难点就是跨主机，还直接通过IP去访问不同主机的Pod
我们先了解一下etcd的作用：etcd是存储管理Flannel可分配的IP地址段资源，监控etcd中每个Pod的实际地址，并在内存中建立维护Pod节点路由表
注意：其实Flannel启动后，会往etcd中插入可以被分配的网段，并且记录已经分配的网络，防止再次被分配给其他网段，造成所谓的IP冲突
图示总结：
在K8S里，总共有三层网络
1.Service网络，是个虚拟网络
2.Pod网络，是个虚拟网络
3.节点网络，真实的物理网络
