KOLLA项目中容器通信探究

一直以来容器通信都是软肋，涉及到数据安全性和服务可靠性。而kolla项目中的容器多达32个，因此很有必要搞清楚这些容器之间是怎么通信的，如何进行消息传输从而提供openstack服务。
网上搜索后发现很少相关的信息，因此自己不断地摸索来找答案。
摸索的思路是这样子的：
首先 看容器之间的通信方式，这里又分为单主机容器之间的通信以及跨主机容器之间的通信，因为我们openstack云操作系统是多节点部署的，每个节点上都有多个容器，因此既会用到单机容器通信也会用到跨主机的容器通信。
然后 再看openstack组件之间和组件内部的通信。kolla将每个组件又做了一次划分，将每个组件中的服务划分为一个容器，这就涉及到openstack组件里的各个服务如何通信。
最后 结合kolla-ansible源码以及多节点部署的实际环境进行分析。在容器构建的时候应该会有容器网络构建的细节，可以从这里进行挖掘。

容器之间的通信方式

单主机容器通信

默认采用bridge的方式，通过linux bridge等方式转发或者数据包的拆封。安装docker的时候会创建一个docker0的网卡，所有容器都是会经过docker0来发出数据。
每个容器启动的时候会随机分配一个ip，ip段即为docker0的配置(网关、掩码、ip段等)。
基于net namespace，docker可以为容器提供隔离的网络环境，在隔离的网络环境找那个可以使容器共享主机或者其他容器的网络命名空间，基本满足在各个场景下的需要。
五种模式
1. bridge模式：我们创建一个新的容器时，容器通过DHCP获取一个与docker0同网段的IP地址，并默认连接到docker0网桥
劣势：与外界通信的时候会占用宿主机的端口，可能会出现与宿主机进行竞争端口资源。需要对宿主机端口进行管理。另外容器与外界通信是基于三层上的iptables NAT，性能和效率有损耗。
2. host模式：直接使用容器宿主机的网络命名空间，没有独立的网络环境，使用宿主机的ip和端口
劣势：容器不再拥有隔离、独立的网络栈。容器会与宿主机竞争网络栈的使用，并且容器的崩溃就可能导致宿主机崩溃。另外容器不再拥有所有的端口资源，因为有些端口已经被主机服务、bridge服务绑定端口等其他服务占用了。
3. none模式：为容器创建独立网络命名空间，但不为它做任何网络配置，容器中只有lo，用户可以在此基础上，对容器网络做任意定制。这个模式下，dokcer不为容器进行任何网络配置。需要我们自己通过第三方工具或者手工方式为容器添加网卡，配置IP。提供最高的灵活度。
因此，若想使用pipework配置docker容器的ip地址，必须要在none模式下才可以。
4. container模式：容器与指定容器共享网络命名空间，但其他不共享，比如文件系统，进程等还是隔离开的。
5. 用户自定义：docker1.9以上支持，允许容器使用第三方的网络实现或者创建单独的bridge网络，提供网络隔离能力
在用户定义网络模式下，开发者可以使用任何docker支持的第三方网络driver来定制容器的网络。并且，docker 1.9以上的版本默认自带了bridge和overlay两种类型的自定义网络driver。可以用于集成calico、weave、openvswitch等第三方厂商的网络实现。bridge driver的所有行为都和默认的bridge模式完全一致。而overlay及其他driver，则可以实现容器的跨主机通信。

两种简单的方式

• 端口映射
  -p 主机端口：容器端口