目录
前言
上一篇文章【k8s】七、Pod详解（一）简单介绍了Pod的基本概念和分类，以及Pod的控制器类型，本篇文章会进一步介绍Pod的网络。涉及概念的东西也比较多，需要各位同学也耐心看一下。但是k8s中的网络不仅仅只是Pod的网络，还有service网络等。
如果还没有k8s实验环境的同学，可以翻看我之前的文章
Pod网络通讯方式
K8S的网络模型假定了所有的Pod都在一个可以直接连通的扁平的网络空间中，也就是说所有的Pod都可以通过对方的IP直接到达。这在GCE（Google Compute Engine）里面是现成的网络模型，K8S假定这个网络已经存在。而在私有云里面搭建K8S集群，就不能假定这个网络已经存在了，我们需要自己实现这个网络假设，将不同节点上的容器之间的互相访问先打通，然后再运行K8S。
不同情况下的网络通讯方式
同一个Pod内部通讯
同一个pod内多个容器之间通过lo通讯。同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈。k8s在启动容器的时候会先启动一个pause容器，这个容器就是实现这个功能的。如上图所示，容器与容器之间是有一个localhost网络，所以，在同一个Pod内部的容器服务的端口不能够重复。否则会报错。
Pod间的通讯
Pod在同一台机器上
如果容器是用Docker的话，那么就通过docker0网桥直接转发。
如果容器是使用Containerd的话，那么是通过CNI进行直接转发。
如图所示，Pod1的IP是172.12.0.100，Pod2的IP是172.12.0.101，两个Pod是在172.12.0.1这个网段下的。
Pod在不同的机器上
Pod地址是在同一个网段，但是CNI/docker0网段与宿主机网卡是两个完全不同的IP网段，并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod之间可以互相访问。此时各个pod之间的通讯可以通过覆盖网络（Overlay Network）方式进行访问。
覆盖网络（Overlay Network），就是在现有网络之上再建立一个虚拟网络，实现技术有很多，例如flannel/weavenet/calico等等，这些方案大都采用隧道封包技术。简单理解，Pod网络的数据包，在出节点之前，会先被封装成节点网络的数据包，当数据包到达目标节点，包内的Pod网络数据包会被解封出来，再转发给节点内部的Pod网络。这种方案对底层网络没有特别依赖，但是封包解包会引入额外性能开销。
Pod 与 Service之间的通讯
各个节点通过Iptables进行维护和转发。pod至service的网络在新版k8s是基于LVS维护和转发
Pod与外网通讯
Pod到外网
Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主机网卡完成路由选择后，iptables执行Masquerade，把源IP更改为宿主网卡的IP，然后向外网服务器发送请求
外网到Pod
通过Service方式进行访问。
CNI
前面我们提到了不同机器上的Pod的通讯方式是通过Overlay Network方式来建立联系的。上面的示意图我们也有提到了CNI。那什么是CNI呢？
什么是CNI
CNI，它的全称是 Container Network Interface，即容器网络的 API 接口。
它是由谷歌和coreos联合制定的一种网络标准，在K8s中标准的一个调用网络实现的接口，也就是实现k8s网络插件的基础。Kubelet 通过这个标准的 API 来调用不同的网络插件以实现不同的网络配置方式，实现了这个接口的就是 CNI 插件，它实现了一系列的 CNI API 接口。常见的 CNI 插件包括 Calico、flannel、Terway、Weave Net 以及 Contiv。
此次我们实验环境用到的CNI插件是Flannel。具体的网络初始化步骤在【k8s】三、k8s集群的初始化里面。下面我们简单介绍一下Flannel
Flannel
Flannel 是CoreOs团队针对Kubernetes设计的一个网络规划服务，简单来说，他的功能是让集群中的不同节点主机创建的容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络（overlay Network），通过这个覆盖网络，将数据包原封不动低传递到目标容器内。
Flannel的网络请求路径
Flannel实质上是一种“覆盖网络(overlay network)”，也就是将TCP数据包装在另一种网络包里面进行路由转发和通信，目前已经支持UDP、VxLAN、AWS VPC和GCE路由等数据转发方式。
默认的节点间数据通信方式是UDP转发。
数据从container中发出后，经由所在主机的docker0/CNI虚拟网卡转发到flannel0虚拟网卡，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。
Flannel通过Etcd服务维护了一张节点间的路由表，详细记录了各节点子网网段 。
源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0/CNI虚拟网卡，最后向本机容器通信一下docker0/CNI路由到达目标容器。
ETCD与Flannel的关联
- 存储管理Flannel可分配的IP地址段资源
- 监控ETCD中每个Pod的实际地址，并在内存中建立未付Pod节点路由表。
总结
本文接着上一篇文章，继续介绍Pod的相关知识点。介绍了Pod的网络在不同情况下的网络通讯方式。以及CNI的部分概念，还有本次实验环境中用到的Flannel网络插件。
写在后面
如果觉得有用的话，麻烦一键三连支持一下攻城狮白玉，并把本文分享给更多的小伙伴。你的简单支持，我的无限创作动力