Docker网络管理之docker跨主机通信

Posted 2020-12-19

前言

由于docker技术的火爆，导致现在越来越多的企业都在使用docker这种虚拟化技术。企业中使用docker这种虚拟化技术，其目的就是为了让docker中的容器对外提供服务。因此，我们必须深入了解一下docker的网络知识，以满足更高的网络需求。

我们安装Docker时，它会自动创建三个网络，bridge（创建容器默认连接到此网络）、 none 、host。

* host：容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。
* None：该模式关闭了容器的网络功能，相当于一个回环网络。
* Bridge：此模式会为每一个容器分配、设置IP等，并将容器连接到一个叫docker0的虚拟网桥，通过docker0网桥以及Iptables nat表配置与宿主机通信。

[root@docker ~]# docker network  ls          //执行该命令查看docker创建的网络
NETWORK ID          NAME                DRIVER              SCOPE
2edf7ef4f9fa        bridge              bridge              local
217d2e9a4785        host                host                local
c0bea73a8e1a        none                null                local

关于上述提到的三个网络解释如下：

• Host：相当于Vmware中的桥接模式，与宿主机在同一个网络中，但没有独立的IP地址。众所周知，Docker使用了Linux的Namespaces技术来进行资源隔离，如PID Namespace隔离进程，Mount Namespace隔离文件系统，Network Namespace隔离网络等。一个Network Namespace提供了一份独立的网络环境，包括网卡、路由、Iptable规则等都与其他的Network Namespace隔离。一个Docker容器一般会分配一个独立的Network Namespace。但如果启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。基于Host模式启动的容器，在容器内执行ifconfig时，看到的都是宿主机上的信息。该模式不够灵活，容易出现端口冲突问题。
• None：该模式将容器放置在它自己的网络栈中，但是并不进行任何配置。实际上，该模式关闭了容器的网络功能，类似于会换地址，在以下两种情况下是有用的：容器并不需要网络（例如只需要写磁盘卷的批处理任务）。
• overlay：顾名思义：覆盖，但它又不是覆盖，它的作用就是在容器原有的网络基础之上，再添加一块网卡，并为其分配一个IP地址，可以将所有的docker容器关联到同一个局域网中，适用于容器与容器是跨主机进行通信的场景。
• Bridge：相当于Vmware中的NAT模式，容器使用独立的network Namespace，并且连接到docker0虚拟网卡（默认模式）。通过docker网桥以及IPtables nat表配置与宿主机通信；Bridge模式是Docker默认的网络设置，此模式会为每一个容器分配一个Network nameSpace、设置IP等，并将一个主机上的Docker容器连接到一个虚拟网桥docker0上

虽然docker模式提供三种网络模式，但其实是有四种网络模式的！
注：今天只介绍Overlay网络，Macvlan网络，想了解其余三种网络模式请参考：https://blog.51cto.com/14306186/2515603

一、Overlay网络

使用overlay网络需事先部署好consul服务！

consul：是一个服务网格（微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控）解决方案，它是一个一个分布式的，高度可用的系统，而且开发使用都很简便。它提供了一个功能齐全的控制平面，主要特点是：服务发现、健康检查、键值存储、安全服务通信、多数据中心。

通过一个实验案例来验证consul服务的特性！
1.案例环境

系统版本： Centos 7.3
Docker版本： 18.09.0
主机名IP地址：
docekr01:192.16.45.129  
docekr02:192.16.45.141   
docekr03:192.16.45.142

2、准备工作：

* 必须安装key-value存储服务，如consul；
* 宿主机已经安装docker engine；
* 宿主机的hostname必须不同 ，避免发生冲突 ；                                       
* 关闭防火墙与SELinux（实验环境；

3、案例实施
1）docker01

[root@docker01 ~]#  docker pull progrium/consul     //下载consul镜像
[root@docker01 ~]#  docker run -d -p 8500:8500 -h consul --name consul  --restart=always progrium/consul -server -bootstrap
//-d：后台运行；              
//-p：将容器中的8500端口映射到宿主机的8500端口；
//-h：表示consul容器的主机名；
//--name：表示运行的容器名；
//--restart=always：随docker服务的启动而启动；
//-server -bootstrap：添加这两个选项，则表示在群集环境中可以使其以master的身份出现；
[root@docker01 ~]# netstat -anpt | grep 8500
tcp6       0      0 :::8500                 :::*                    LISTEN      3725/docker-proxy   
//确定其8500端口正在监听
[root@docker01 ~]# vim /usr/lib/systemd/system/docker.service     //更改一下docker的主配置文件
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376 --cluster-store=consul://192.168.45.129:8500 --cluster-advertise=ens33:2376
//在第13行上原本的基础添加以上内容，各个配置项含义如下：
# /var/run/docker.sock：Docker的一个套接字；
# “ -H tcp://0.0.0.0:2376 ” ：使用本机的tcp2376端口；
# “ --cluster-store=consul://192.168.45.129:8500”：指定运行着consul服务的docker服务器IP及端口；
# “ --cluster-advertise=ens33:2376”：从本机的ens33网卡通过2376端口搜集网络信息，存储在consul上
[root@docker01 ~]# systemctl  daemon-reload 
[root@docker01 ~]# systemctl  restart docker.servic     //重新启动docker服务

使用浏览器访问consul服务的web页面



2）docker02

[root@docker02 ~]# vim /usr/lib/systemd/system/docker.service 
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376 --cluster-store=consul://192.168.45.129:8500 --cluster-advertise=ens33:2376
//在第13行上原本的基础添加以上内容，各个配置项含义如下：
# /var/run/docker.sock：Docker的一个套接字；
# “ -H tcp://0.0.0.0:2376 ” ：使用本机的tcp2376端口；
# “ --cluster-store=consul://192.168.45.129:8500”：指定运行着consul服务的docker服务器IP及端口；
# “ --cluster-advertise=ens33:2376”：从本机的ens33网卡通过2376端口搜集网络信息，存储在consul上
[root@docker02 ~]# systemctl  daemon-reload 
    [root@docker02 ~]# systemctl  restart docker.service    //重新启动docker服务

访问浏览器刷新浏览器页面

3）Docker3

Docker3与Docker2的操作就是一模一样的，所以这里就不多做解释了！

[root@docker03 ~]# vim /usr/lib/systemd/system/docker.service 
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2376 --cluster-store=consul://192.168.45.129:8500 --cluster-advertise=ens33:2376
//在第13行上原本的基础添加以上内容，各个配置项含义如下：
# /var/run/docker.sock：Docker的一个套接字；
# “ -H tcp://0.0.0.0:2376 ” ：使用本机的tcp2376端口；
# “ --cluster-store=consul://192.168.45.129:8500”：指定运行着consul服务的docker服务器IP及端口；
# “ --cluster-advertise=ens33:2376”：从本机的ens33网卡通过2376端口搜集网络信息，存储在consul上
[root@docker03 ~]# systemctl  daemon-reload 
[root@docker03 ~]# systemctl  restart docker.service    //重新启动docker服务

注：如果在此过程中，访问web页面如果出现“500”的错误页面，将运行consul服务的容器删除重新创新即可！
4）创建一个 overlay网络
docker01：

[root@docker01 ~]# docker network create -d overlay my_olay
//创建一个名为my_olay的voerlay网络 
//以上操作不管在那台docker主机上操作都可以
[root@docker01 ~]#  docker network create -d overlay --subnet 200.0.0.0/24 --gateway 200.0.0.1 lv_olay
//也可以在创建overlay网卡时，指定其IP网段及网关
[root@docker01 ~]# docker network ls          //查看docker所支持的网络

注：

• 而且在另外两台docker服务器上也可看到，自行验证！

• 在docker 1上创建的网络，可以看到其SPOCE（范围）定义的是global（全局），那么这就意味着加入consul这个服务群集的其他docker服务器也可以看到这张网卡！

• 如果在创建网卡时，没有指定其网段，则默认是10.0.0.0网段，由于是自定义网络，所以满足自定义网络的特征（比如支持容器之间的通信）！
  5）在不同的docker服务器各自创建一个容器，验证是否可以通信！

  [root@docker01 ~]# docker run -itd --name t1 --network lv_olay --ip 200.0.0.10 busybox:latest
  //在docker1服务器上创建一个名为t1的容器并指定其IP地址
  [root@docker02 ~]#  docker run -itd --name t2 --network lv_olay --ip 200.0.0.20 busybox:latest
  //在docker2上创建一个容器并指定IP地址
  [root@docker03 ~]# docker run -itd --name t3 --network lv_olay --ip 200.0.0.30 busybox:latest
  //在docker3上创建一个容器并指定IP地址
  [root@docker01 ~]# docker exec -it t1 /bin/sh
  //随便在一台docker服务器上进入其创建的容器中，进行测试
  / # ping  -c 2  t2
  PING t2 (200.0.0.20): 56 data bytes
  64 bytes from 200.0.0.20: seq=0 ttl=64 time=1.053 ms
  64 bytes from 200.0.0.20: seq=1 ttl=64 time=1.052 ms
  / # ping  -c 2  t3
  PING t3 (200.0.0.30): 56 data bytes
  64 bytes from 200.0.0.20: seq=0 ttl=64 time=1.053 ms
  64 bytes from 200.0.0.20: seq=1 ttl=64 time=1.052 ms

  注：可以看出IP地址，不同docker host上容器通信是没有问题的；