k8s——3.网络通讯方式

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.节点网络，真实的物理网络