- Kuberbetes的网络模型假定了所有的Pod都在一个可以直接联通的扁平的网络空间中,这在GCE(Google Compute Engine)里面是现成的网络模型,Kuberbetes假定这个网络已经存在,而在私有云搭建Kuberbetes集群,就不能假定这个网络已经存在了,我们需要自己实现这个网络假设,将不同节点上的Docker容器之间的互相访问先打通,然后运行Kuberbetes。
- 同一个pod内的多个容器之间访问模式是通过pause进行lo(localhost)相互访问
同一个pod共享一个网络命名空间,共享一个Linux协议栈- 各Pod之间的通讯:Overlay Network (全覆盖网络)
1、Pod1与Pod2不在同一台主机,Pod的地址是与Docker0在同一个网段的,但docker0网段与宿主机网卡是两个完全不同的IP网段,并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在的Node的IP关联起来,通过这个关联让Pod可以互相访问
2、Pod1与Pod2在同一台机器,由Docker0网桥直接转发请求至Pod2,不需要经过Flannel- Pod与Service 之间的通讯: 各节点的Iptables规则
目前基于性能考虑,全部为iptables维护和转发。目前使用LVS进行转发性能会更高
- Pod到外网:Pod向外网发送请求,查找路由表,转发数据包到宿主机的网卡,宿主网卡完成路由选择后,iptables执行Masquerade,把源IP地址更改为宿主网卡的IP,然后向外网服务器发送请求
- 外网访问Pod:service
节点网络:是真实的网卡网络,pod网络和Service网络都是虚拟网络
Flannel 是centos团队针对Kuberbetes设计的一个网络规划服务,简单来说,它的功能是让集群中不同节点的主机创建的Docker容器都具有全集群唯一的虚拟IP地址,而且他还能在这些IP地址之间建立一个覆盖网络(overlay network),通过这个覆盖网络,将数据包原封不动的传递到目标容器内
Etcd之Flannel提供说明
- 存储管理Flannel可分配的IP地址段资源
- 监控Etcd的实际地址,并在内存中建立维护Pod节点路由表