Kubernetes---网络通讯模式笔记

kubernetes网络通讯模式     Kubernetes的网络模型假定了所有Pod都在一个可以直接连通的扁平的网络空间中,这在GCE(Google Compute Engine)里面是现成的网络模型,Kubernetes假定这个网络已经存在。而在私有云里搭建Kubernetes集群,就不能假定这个网络已经存在了。我们需要自己实现这个网络假设,将不同节点上的Docker容器之间的互相访问先打通,然后运行Kubernetes。
    同一个Pod内的多个容器之间网络互访:基于Pause容器的网络栈Lo(共享网卡)     各个Pod之间的网络通信:Overlay Network     Pod与Service之间的通讯:各节点的IpTables规则【新版本中已经加入了LVS机制,转发效率将会更高,上限也更高】
    Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。而且它还能在这些IP地址之间建立一个覆盖网络(Overlay Network),通过这个覆盖网络,将数据包原封不动地传递到目标容器内。
Flavnel和ETCD之间的关联     存储管理Flannel可分配的IP地址段资源         Flannel启动以后会向ETCD里插入可以被分配的网段,并且把那些网段分配给那些机器了都记录上,防止已经分配的网段再次被Flannel利用分配给其他的Node节点     监控ETCD中每个Pod的实际地址,并在内存中建立维护Pod节点路由表
杂乱记录:     同一个Pod内部通讯:同一个Pod共享同一个网络命名空间,共享同一个Linux协议栈     Pod1至Pod2         Pod1与Pod2不在同一台主机,Pod的地址是与docker0在同一个网段的,但docker0网段与宿主机网卡是两个完全不同的IP网段,并且不同Node之间的通信只能通过宿主机的物理网卡进行。将Pod的IP和所在Node的IP关联起来,通过这个关联让Pod可以互相访问。         Pod1与Pod2在同一台机器,由docker0网桥直接转发请求至Pod2,不需要经过Flannel     Pod至Service的网络:目前基于性能考虑,全部为iptables维护和转发。最新版已经完全可以由LVS进行转发和维护。     Pod到外网:Pod向外网发送请求,查找路由表,转发数据包到宿主机的网卡,宿主网卡完成路由选择后,iptables执行Masquerade,把源IP更改为宿主网卡的IP,然后向外网服务器发送请求。     外网访问Pod:Service
    **在Kuberbetes中,只有Node网络是真实存在的,Pod以及Service网络都是虚拟网络


上一篇:kubernetes使用flannel网络插件服务状态显示CrashLoopBackOff


下一篇:windows搭建redis集群最佳实践