Docker实验Docker的网络配置

一.基本网络配置–docker网络模式    https://blog.csdn.net/qq_39376481/article/details/95054890

• docker的镜像是令人称道的地方,但网络功能还是相对薄弱的部分。
• docker安装后会自动创建3种网络:bridge、host、none

Docker在启动时会开启一个虚拟网桥设备docker0，默认的地址为172.17.0.1/16，容器启动后都会被桥接到docker0上，并自动分配到一个ip地址
实验：
1.查看docker的网络有哪些（发现有三种， bridge，host，none）

[root@server1 ~]# docker network ls

2.查看server1上的ip，发现docker0

[root@server1 ~]# ip addr

• 1

二.基本网络配置–容器的四种网络模式

（一）docker网络中的bridge网络模式
bridge模式下容器没有一个公有ip,只有宿主机可以直接访问,外部主机是不可见的,但容器通过宿主机的NAT规则后可以访问外网。

Bridge 桥接模式的实现步骤主要如下：

• Docker Daemon 利用 veth pair 技术，在宿主机上创建两个虚拟网络接口设备，假设为veth0 和 veth1。而 veth pair 技术的特性可以保证无论哪一个 veth 接收到网络报文，都会将报文传输给另一方。
• Docker Daemon 将 veth0 附加到 Docker Daemon 创建的 docker0 网桥上。保证宿主机的网络报文可以发往 veth0；
• Docker Daemon 将 veth1 添加到 Docker Container 所属的 namespace 下，并被改名为 eth0。如此一来，保证宿主机的网络报文若发往 veth0，则立即会被 eth0 接收，实现宿主机到Docker Container 网络的联通性；同时，也保证 Docker Container 单独使用 eth0，实现容器网络环境的隔离性

Bridge桥接模式的缺陷：

• 1.最明显的是，该模式下 Docker Container 不具有一个公有 IP，即和宿主机的 eth0 不处于同一个网段。导致的结果是宿主机以外的世界不能直接和容器进行通信。
• 2.虽然 NAT 模式经过中间处理实现了这一点，但是 NAT 模式仍然存在问题与不便，如：容器均需要在宿主机上竞争端口，容器内部服务的访问者需要使用服务发现获知服务的外部端口等。
• 3.另外 NAT 模式由于是在三层网络上的实现手段，故肯定会影响网络的传输效率。

实验：
1.创建一个别名为vm1的容器并查看其ip，发现其ip为 172.17.0.3/16（这是因为当容器桥接docker0后，会自动分配ip地址，然后逐渐递增）

[root@server1 ~]# docker run -it --name vm1 ubuntu
root@6269c5f20354:/# ip addr

 

2.设备vethed03df5连接在了docker0上
#docker安装时会创建一个名为 docker0 的Linux bridge,新建的容器会自动桥接到这个接口。

[root@server1 ~]# brctl show

 

3.查看真实物理机上的ip，发现多了一个虚拟网卡，且注意vethed03df5@if4与容器间的是成对的

[root@server1 ~]# ip addr show

 

4.查看vm1的情况中的Pid（每个容器都会有一个独立的Pid）

[root@server1 ~]# docker inspect vm1 | grep Pid

 

5.查看关于此Pid容器网络的文件（每一个独立的Pid都会在/proc目录下有一个相应的以Pid为名的目录，这个目录里面的ns目录有着关于这个Pid容器网络的文件）：

[root@server1 ~]# cd /proc/1872/
[root@server1 1872]# ls
[root@server1 1872]# cd ns/
[root@server1 ns]# ll

 

注意：
veth设备是成双成对出现的，一端是容器内部命名为eth0，一端是加入到网桥并命名的veth*（通常命名为veth*），它们组成了一个数据传输通道，一端进一端出，veth设备连接了两个网络设备并实现了数据通信

（二）docker网络中的host网络模式

• host网络模式需要在容器创建时指定–network=host
• host 模式是 bridge 桥接模式很好的补充。采用 host 模式的 Docker Container，可以直接使用宿主机的 IP 地址与外界进行通信，若宿主机的 eth0 是一个公有 IP，那么容器也拥有这个公有 IP。同时容器内服务的端口也可以使用宿主机的端口，无需额外进行 NAT 转换。
• host模式可以让容器共享宿主机网络栈,这样的好处是外部主机与容器直接通信,但是容器的网络缺少隔离性。
  
  Host 网络模式的缺陷：
• 最明显的是 Docker Container 网络环境隔离性的弱化。即容器不再拥有隔离、独立的网络栈。
• 另外，使用 host 模式的 Docker Container 虽然可以让容器内部的服务和传统情况无差别、无改造的使用，但是由于网络隔离性的弱化，该容器会与宿主机共享竞争网络栈的使用；
• 另外，容器内部将不再拥有所有的端口资源，原因是部分端口资源已经被宿主机本身的服务占用，还有部分端口已经用以 bridge 网络模式容器的端口映射。

实验：
1.重新创建host网络模式的一个容器vm2并查看ip，会发现此时的ip与宿主机（docker0）中的ip一样

[root@server1 ~]# docker run -it --name vm2 --network=host ubuntu
root@server1:/# ip addr
root@server1:/# [root@server1 ~]#

 

2.证明（容器vm2中的ip和宿主机（docker0）中的ip一样）：

[root@server1 ~]# ip a

 

（三）docker网络中的none网络模式

• none模式是指禁用网络功能,只有lo接口,在容器创建时使用–network=none指定。
• 网络环境为 none,即不为 Docker Container 任何的网络环境。一旦 Docker Container 采用了none 网络模式,那么容器内部就只能使用 loopback 网络设备,不会再有其他的网络资源。可以说 none 模式为 Docker Container 做了极少的网络设定,但是俗话说得好“少即是多”,在没有网络配置的情况下,作为 Docker 开发者,才能在这基础做其他无限多可能的网络定制开发。这也恰巧体现了 Docker 设计理念的开放。

实验：
创建一个none网络模式的容器vm3并查看ip，会发现此时只有lo接口

[root@server1 ~]# docker run -it --name vm3 --network=none ubuntu
root@5a2991d10db2:/# ip addr

 

（四）docker网络中的Container网络模式

• Container 网络模式是 Docker 中一种较为特别的网络的模式。在容器创建时使用–network=container:vm1指定。(vm1指定的是运行的容器名)
• 处于这个模式下的 Docker 容器会共享一个网络栈,这样两个容器之间可以使用localhost高效快速通信。
  
• 缺陷：它并没有改善容器与宿主机以外世界通信的情况（和桥接模式一样，不能连接宿主机以外的其他设备）。

实验：
创建一个container网络模式的容器vm4并查看ip，由于vm4使用的是vm1的网络，所以其查看的网络结果和vm1的相同

[root@server1 ~]# docker run -it --name vm4 --network=container:vm1 ubuntu
root@6269c5f20354:/# ip addr

 

 

（五）使用link方式使容器间可以相互通信
docker run --link可以用来链接2个容器，使得源容器（被链接的容器）和接收容器（主动去链接的容器）之间可以互相通信，并且接收容器可以获取源容器的一些数据，如源容器的环境变量。
实验：
1.创建一个容器vm5，并使用link方式连接vm1

#此时的vm1的是容器名，db1是容器的别名
[root@server1 ~]# docker run -it --name vm5 --link vm1:db1 ubuntu
#查看当前环境的环境变量
root@b814d53a605c:/# env

 

2.尝试去连接vm1以及其别名，发现可以成功连接

root@b814d53a605c:/# ping vm1
root@b814d53a605c:/# ping db1

 

3.查看其ip，发现是172.17.0.4/16，说明ip是递增的（之前只有容器vm1时才为其自动分配了ip

root@b814d53a605c:/# ip a 

 

4.查看容器中的域名解析，可以发现每一个ip对应的主机名

root@b814d53a605c:/# cat /etc/hosts

 

三.高级网络配置–网桥

• 自定义网络模式中，docker提供了三种自定义网络驱动：brdge，overlay，macvlan，bridge驱动类似默认的bridge网络模式，但增加了一些新的功能，overlay和macvlan是用于创建跨主机网络
• 建议使用自定义的网络来控制哪些容器可以相互通信，还可以自动DNS解析容器名称到IP地址

实验：
（一）bridge自定义网络

• 自定义网桥中会自己分配ip地址和网关地址）
  1.创建自定义网桥并查看

  #以下命令也可以写成以下格式：[root@server1 ~]# docker network create --driver bridge my_net1
  [root@server1 ~]# docker network create my_net1
  [root@server1 ~]# docker network ls

2.为了不影响之后的实验，将所有的容器都进行关闭
#查看正在运行的容器

[root@server1 ~]# docker ps

 

#将正在运行的容器强制删除

[root@server1 ~]# docker rm -f vm1
[root@server1 ~]# docker rm -f vm3
[root@server1 ~]# docker rm -f vm4
[root@server1 ~]# docker rm -f vm5

 

#查看没有运行的容器

[root@server1 ~]# docker ps -a

 

#将其也依次删除，使其环境纯净

[root@server1 ~]# docker rm -f vm2
[root@server1 ~]# docker rm -f registry

 

 

3.查看自定义网络的ip地址和网关地址

[root@server1 ~]# ip a
[root@server1 ~]# docker network inspect my_net1

 

4.创建容器vm1并使用自定义网桥，并尝试与vm1通信，发现可以通信

[root@server1 ~]# docker run -it --name vm1 --network=my_net1 ubuntu
#在通信时
root@ea41dabc161f:/# ping vm1

 

5.创建容器vm2并使用自定义网桥，并尝试与vm1通信，发现可以通信

[root@server1 ~]# docker run -it --name vm2 --network=my_net1 ubuntu
#在通信时可以发现vm1自动进行了域名解析
root@010fe2d13a0b:/# ping vm1

 

总结：
在创建容器时，如果使用的网络模式时自定义的网桥，那么在此网桥中创建的容器都可以互相进行通信。

（二）bridge自定义网络–网段

• 还可以自己定义网段：在创建时指定参数:–subnet 、–gateway
• 创建两个容器,并桥接到不同的网桥上（vm1连接的网桥是my_net1）,彼此是不通信的。
• 使用–ip参数可以指定容器ip地址,但必须是在自定义网桥上,默认的bridge模式不支持,同一网桥上的容器是可以互通的。

实验：
1.添加一个docker的自定义网段并查看

[root@server1 ~]# docker network create --subnet=172.21.0.0/24 --gateway=172.21.0.1 my_net2
[root@server1 ~]# docker network ls

 

2.创建一个容器vm3，并设置其ip（ip必须在自定义桥内）

[root@server1 ~]# docker run -it --name vm3 --network=my_net2 --ip=172.21.0.100  ubuntu
root@0f6d07ab74f1:/# ip a

 

3.尝试通信vm1，发现无法通信；尝试通信vmm3，发现可以通信。说明如果使用不同网桥间的容器时不可以通讯的

root@0f6d07ab74f1:/# ping vm1
root@0f6d07ab74f1:/# ping vm3

• 1
• 2

（三）不同网桥间的容器进行通信

• docker在设计上就是要隔离不同的network的
• dokcer作为一个超级厉害的容器，怎么能容忍不同网桥间无法进行通信，它当然有其自己的方法。

前提：
现在使用的容器vm1使用的网桥时my_net1，容器vm3使用的网桥是my_net2，默认是无法进行通讯的

实验：
1.使用 docker network connect命令为vm1添加一块my_net2 的网卡。

#给容器添加网卡后可以连接不同网络
[root@server1 ~]# docker network connect my_net2 vm1

 

2.进入容器vm1（因为vm1此时正在运行，所以可以使用attach直接进入vm1容器），并查看ip，发现此时多了一块网卡，且自动分配了ip，然后尝试与vm3进行通信，发现可以成功通讯

[root@server1 ~]# docker attach vm1
root@ea41dabc161f:/# 
root@ea41dabc161f:/# ip a
root@ea41dabc161f:/# ping vm3

 

 

3.容器之间除了使用ip通信外,还可以使用容器名称通信

#docker 1.10开始,内嵌了一个DNS server，但是dns解析功能必须在自定义网络中使用
root@ea41dabc161f:/# ping -c1 vm1
root@ea41dabc161f:/# ping -c1 vm3

 

总结：
1.docker的bridge自定义网络（自定义网络中的网桥）间可以随便添加对方的网卡
2.docker的bridge自定义网络与系统自带的网桥自己间：只能是系统自带的网桥对应的容器添加给自定义的网桥间，而反过来会报错
3.docker的系统自带的网桥之间时可以互相通信的，因为在同一个网络桥接上

四.容器访问外网以及外网访问容器

• 容器如何访问外网？其是通过iptables的SNAT实现的
  

• 外网如何访问容器？通过端口映射以及选项指定映射端口

• 外网访问容器用到了docker-proxy和iptables DNAT
  宿主机访问本机容器使用的是iptables DNAT
  外部主机访问容器或容器之间的访问是docker-proxy实现
  
  实验：
  1.首先查看原来的防火墙策略

  [root@server1 ~]# iptables -t nat -nL

2.运行镜像nginx并设置映射的端口

[root@server1 ~]# docker run -d --name nginx -p 80:80 nginx

 

3.查看容器的端口

[root@server1 ~]# docker port nginx
[root@server1 ~]# netstat -antlp | grep 80

 

4.再次查看防火墙的策略

[root@server1 ~]# iptables -t nat -nL

 

5.访问172.17.0.2,172.17.0.1和localhost，发现都可以成功访问，说明防火墙策略设置成功并实现了容器和外网之间相互通信

[root@server1 ~]# curl 172.17.0.2
[root@server1 ~]# curl localhost
[root@server1 ~]# curl 172.17.0.1

 

五.网络解决方案（跨主机）

• 跨主机网络解决方案：docker原生的overlay和macvlan，第三方的flannel,weave,calico
• 众多网络方案是如何与docker集成在一起的：libnetwork docker容器网络库；CNM(Container Network Model)这个模型对容器网络进行了抽象
• CNM分三类组件
  1.Sandbox:容器网络栈,包含容器接口、dns、路由表。(namespace)
  2.Endpoint:作用是将sandbox接入network (veth pair)
  3.Network:包含一组endpoint,同一network的endpoint可以通信。
  

macvlan网络方案实现：

• Linux kernel提供的一种网卡虚拟化技术。
• 无需Linux bridge,直接使用物理接口,性能极好。
• macvlan本身是linxu kernel的模块，本质上是一种网卡虚拟化技术。其功能是允许在同一个物理网卡上虚拟出多个网卡，通过不同的MAC地址在数据链路层进行网络数据的转发，一块网卡上配置多个 MAC 地址（即多个 interface），每个interface可以配置自己的IP，Docker的macvlan网络实际上就是使用了Linux提供的macvlan驱动。
• macvlan网络间的隔离和连通
  （1）macvlan网络在二层上是隔离的,所以不同macvlan网络的容器是不能通信的。
  （2）可以在三层上通过网关将macvlan网络连通起来。
  （3）docker本身不做任何限制,像传统vlan网络那样管理即可。

实验：
（一）打开混杂模式

1.首先在server1中添加一块网卡


2.在server1中查看，发现多了一个新的网卡eth1

[root@server1 ~]# ip addr show

 

3.在server1中添加网卡配置文件并启动网卡

[root@server1 ~]# cd /etc/sysconfig/network-scripts/
[root@server1 network-scripts]# ls
[root@server1 network-scripts]# cp ifcfg-eth0 ifcfg-eth1
[root@server1 network-scripts]# vim ifcfg-eth1
[root@server1 network-scripts]# cat ifcfg-eth1
[root@server1 network-scripts]# ifup eth1
[root@server1 network-scripts]# ip addr

 

文件ifcfg-eth1中的内容如下：

BOOTPROTO=static
ONBOOT=yes
DEVICE=eth1

 

4.在server2中要添加网卡并进行相应的配置，然后启动



5.打开server1和srver2的eth1网卡的混杂模式并查看其是否是混杂模式（PROMISC）

[root@server1 ~]# ip link set eth1 promisc on
[root@server1 ~]# ip addr show | grep eth1
[root@server2 ~]# ip link set eth1 promisc on
[root@server2 ~]# ip addr show | grep eth1

注意：
1.因为多个MAC地址的网络数据包都是从同一块网卡上传输，所以需要打开网卡的混杂模式
2.如果不开启混杂模式，会导致macvlan网络无法访问外界，具体在不使用vlan时，表现为无法ping通路由以及同一网络内他其他主机

6.删除容器，避免影响接下来的实验

[root@server1 ~]# docker ps -a
# 查看所有容器的container id
[root@server1 ~]# docker ps -qa
# 一次性关闭
[root@server1 ~]# docker rm -f `docker ps -qa`
[root@server1 ~]# docker ps -a

 

（二）在两台主机上各创建macvlan网络并使用创建的网络运行容器
server1：
1.在server1上创建macvlan网络:

# -o指父接口
[root@server1 ~]# docker network create -d macvlan --subnet=172.22.0.0/24 --gateway=172.22.0.1 -o parent=eth1 macvlan1
[root@server1 ~]# docker network ls
[root@server1 ~]# brctl show

 

2.将server1中不需要的自定义网络删除（我知道很唐突，但是看着实在难受）

[root@server1 ~]# docker network rm my_net1 
[root@server1 ~]# docker network rm my_net2
[root@server1 ~]# docker network ls

 

3.在server1中创建一个容器并使用macvlan网络，并设置ip为172.25.0.10

[root@server1 ~]# docker run -it --name vm1 --network=macvlan1 --ip=172.22.0.10 ubuntu
root@cb1d34c71d79:/# ip addr

 

补充：
macvlan模式不依赖网桥，所以如果使用brctl show查看时会发现并没有创建新的bridge，但是查看容器的网络时，会看到虚拟网卡对应了一个interface是26，而此时查看宿主机的网络时会发现26正是虚拟机的eth1网卡

总结：
由上可见，容器的eth0就是宿主机的eth0通过macvlan虚拟出来的接口，容器的接口直接与主机的网卡连接，这种方法使得容器无需通过NAT和端口映射就能与外网直接通信（只要有网卡），在网络上看起来与其他独立主机没有区别

4.在server1中再次创建一个容器并使用macvlan网络，并设置ip为172.23.0.11

[root@server1 ~]# docker run -it --name vm2 --network=macvlan1 --ip=172.22.0.11 ubuntu
root@b5c839190bbe:/# ip addr
#发现可以ping通vm1
root@b5c839190bbe:/# ping vm1

server2：
5.在server2中创建macvlan网络并查看

[root@server2 ~]# docker network create -d macvlan --subnet=172.22.0.0/24 --gateway=172.22.0.1 -o parent=eth1 macvlan1
[root@server2 ~]# docker network ls

6.在server2中导入ubuntu镜像

[root@server2 ~]# docker load -i ubuntu.tar 

• 1

7.在server2中创建一个容器并使用macvlan网络，设置ip为172.25.0.12，尝试与172.25.0.10和172.25.0.11通信，发现可以成功通信

[root@server2 ~]# docker run -it --name vm3 --network=macvlan1 --ip=172.22.0.12 ubuntu
root@7cf65030033d:/# ping 172.22.0.10
root@7cf65030033d:/# ping 172.22.0.11

 

 

（三）macvlan会独占主机的网卡的解决方案

• macvlan会独占主机网卡，但可以使用vlan子接口实现多macvlan网络
• vlan可以将物理二层网络划分为4094个逻辑网络,彼此隔离,vlan id取值为1~4094
• 网络模型对比
  （1）Docker overlay 建立主机间 VxLAN 隧道,原始数据包在发送端被封装成 VxLAN 数据包,到达目的后在接收端解包。
  （2）Macvlan 网络在二层上通过 VLAN 连接容器,在三层上依赖外部网关连接不同macvlan。数据包直接发送,不需要封装,属于 underlay 网络。
  （3）Flannel 的两种 backend:vxlan 和 host-gw。vxlan 与 Docker overlay 类似，属于overlay 网络。host-gw 将主机作为网关,依赖三层 IP 转发,不需要vxlan 那样对包进行封装,属于 underlay 网络。
  （4）Weave 是 VxLAN 实现,属于 overlay 网络。
• 分布式存储
  （1）Docker Overlay、Flannel 和 Calico 都需要 etcd 或 consul。
  （2）Macvlan 是简单的 local 网络,不需要保存和共享网络信息。
  （3）Weave 自己负责在主机间交换网络配置信息,也不需要Distributed Store。
• IP地址管理
  （1）Docker Overlay 所有主机共享同一个子网,容器启动时会顺序分配 IP。
  （2）Macvlan 需要用户自己管理子网,不同子网通信依赖外部网关。
  （3）Flannel 为每个主机自动分配独立的子网,用户只需要指定一个大的 IP 池。不同子网之间的路由信息也由 Flannel 自动生成和配置。
  （4）Weave 默认所有容器使用 10.32.0.0/12子网。
  （5）Calico 从定制IP池中为每个主机分配自己的子网。
• 连通与隔离
  （1）同一 Docker Overlay 网络中的容器可以通信,但不同网络之间无法通信,要实现跨网络访问,只有将容器加入多个网络。与外网通信可以通过 docker_gwbridge网络。
  （2）Macvlan 网络的连通或隔离完全取决于二层 VLAN 和三层路由。
  （3）不同 Flannel 网络中的容器直接就可以通信,没有提供隔离。与外网通信可以通过 bridge 网络。
  （4）Weave 网络默认配置下所有容器在一个大的子网中,可以自由通信,如果要实现隔离,需要为容器指定不同的 subnet 或 IP。与外网通信的方案是将主机加入到weave 网络，并把主机当作网关。
  （5）Calico 默认配置下只允许位于同一网络中的容器之间通信,但通过其强大的Policy 能够实现几乎任意场景的访问控制。
• 性能
  （1）最朴素的判断是:Underlay 网络性能优于 Overlay 网络。
  （2）Overlay 网络利用隧道技术,将数据包封装到 UDP 中进行传输。因为涉及数据包的封装和解封,存在额外的 CPU 和网络开销。虽然几乎所有 Overlay 网络方案底层都采用Linux kernel 的 vxlan 模块,这样可以尽量减少开销,但这个开销与Underlay 网络相比还是存在的。所以 Macvlan、Flannel host-gw、Calico 的性能会优于 Docker overlay、Flannel vxlan 和 Weave。
  （3）Overlay 较 Underlay 可以支持更多的二层网段,能更好地利用已有网络,以及有避免物理交换机 MAC 表耗尽等优势,所以在方案选型的时候需要综合考虑
• macvlan的性能非常好
  overlay偏向应用层（更丰富，但是性能上有点损耗）
  ct主要指网络

1.创建vlan子接口并查看

[root@server1 ~]# docker network create -d macvlan --subnet=172.23.0.0/24 --gateway=172.23.0.1 -o parent=eth1.1 macvlan2
[root@server1 ~]# docker network ls

• 1
• 2

2.再次创建一个容器且ip为172.23.0.11，此时尝试与172.22.0.10通信，发现无法通信

[root@server1 ~]# docker run -it --name vm3 --network=macvlan2 --ip=172.23.0.11 ubuntu
root@5d9460b74f05:/# ip addr
root@5d9460b74f05:/# ping 172.22.0.10

 

3.因为各个vlan子接口创建的容器之间是可以相互通信的，所以给容器vm3添加vlan子接口并连接vm3

[root@server1 ~]# docker network connect macvlan1 vm3
[root@server1 ~]# docker attach vm3
root@5d9460b74f05:/# 
root@5d9460b74f05:/# ip addr

 

4.连接vm3后，发现可以成功与172.25.0.10/172.25.0.11/172.22.0.12进行通信

root@5d9460b74f05:/# ping 172.22.0.10
root@5d9460b74f05:/# ping 172.22.0.11
root@5d9460b74f05:/# ping 172.22.0.12

 

总结：
172.22.0.10是server1中容器vm1的ip
172.22.0.11是server1中容器vm2的ip
172.22.0.12是server2中容器vm3的ip
172.23.0.11是server1中容器vm3的ip
当macvlan独占主机的网卡时，一个网卡只能创建一个macvlan网络，解决的方案是创建vlan的子接口并在创建新的容器时进行连接，之后给容器添加vlan子接口，大功告成