docker容器网络

利用Net Namespace可以为Docker容器创建隔离的网络环境，容器具有完全独立的网络栈，与宿主机隔离。也可以使Docker容器共享主机或者其他容器的网络命名空间，基本可以满足开发者在各种场景下的需要。

Docker支持 4种网络模式 ：

1）host模式，--net=host指定，不支持多主机。

2）container模式，--net = container : name_or_id指定，不支持多主机。

3）none模式，--net=none指定，不支持多主机。

4）bridge模式，--net=bridge指定，默认设置，不支持多主机。

启动容器的时候使用Host模式，那么该容器与宿主机共用一个Network Namespace，因此容器将不会虚拟自己的网卡、配置自己的IP等，而是使用宿主机的IP和端口。

采用Host模式的容器，可以直接使用宿主机的IP地址与外界进行通信，无需额外进行NAT转换。由于容器通信时，不再需要通过Linux Bridge等方式转发或者数据包的拆封，性能上有很大优势。当然， Host模式有利也有弊 ，主要包括以下缺点：

1）容器没有隔离、独立的网络栈。容器因与宿主机共用网络栈而争抢网络资源，并且容器崩溃也可能导致宿主机崩溃，这在生产环境中是不允许发生的。

2）容器不再拥有所有的端口资源，因为一些端口已经被宿主机服务、Bridge模式的容器端口绑定等其他服务占用了。

需要补充说明的是，Host模式下的容器仅仅是网络命名空间与主机相同，但容器的文件系统、进程列表等还是和与宿主机隔离的。

Container模式是一种特殊的网络模式。该模式下的容器使用其他容器的网络命名空间，网络隔离性会处于Bridge模式与Host模式之间。当容器与其他容器共享网络命名空间时，这两个容器间不存在网络隔离，但它们与宿主机及其他容器又存在网络隔离。

在Kubernetes体系架构下引入Pod概念，Kubernetes为Pod创建一个基础设施容器， 同一Pod下的其他容器都以Container模式 共享这个基础设施容器的网络命名空间，相互之间以localhost访问，构成一个统一的整体。

与前两种不同，None模式的Docker容器拥有自己的Network Namespace，但并不为Docker容器进行网络配置。该Docker容器没有网卡、IP、路由等信息。需要用户为Docker容器添加网卡、配置IP等。

Bridge模式是Docker默认的网络模式，也是开发者最常使用的网络模式。在这种模式下，Docker为容器创建独立的网络栈，保证容器内的进程使用独立的网络环境，实现容器之间、容器与宿主机之间的网络栈隔离。同时，通过宿主机上的Docker0网桥，容器可以与宿主机乃至外界进行网络通信。

同一宿主机上，容器之间都是连接在Docker0这个网桥上，Docker0作为虚拟交换机使容器间相互通信 。但是， 由于宿主机的IP地址与容器veth pair的IP地址均不在同一个网段 ，故仅仅依靠 veth pair和NameSpace的技术 并不足以使宿主机以外的网络主动发现容器的存在。Docker采用了 端口绑定的方式(通过iptables的NAT) ，将宿主机上的端口流量转发到容器内的端口上，这样一来，外界就可以与容器中的进程进行通信。 iptables的介绍，请点我点我 。

创建容器，并将宿主机的3306端口绑定到容器的3306端口：docker run -tid --name db -p 3306:3306 mysql

在宿主机上，可以通过“iptables -t nat -L -n”，查到一条DNAT规则：DNAT tcp --0000/0 0000/0 tcp dpt:3306 to:1721705:3306

Bridge模式的容器与外界通信时，必定会占用宿主机上的端口，从而与宿主机竞争端口资源，这会造成对宿主机端口管理很复杂。同时，由于容器与外界通信是基于三层上iptables NAT，性能和效率损耗是显而易见的。

NAT将地址空间分段的做法引入了额外的复杂度。比如容器中应用所见的IP并不是对外暴露的IP， 因为网络隔离，容器中的应用实际上只能检测到容器的IP，但是需要对外宣称的则是宿主机的IP，这种信息的不对称将带来诸如破坏自注册机制等问题 。

摘抄自陆平的《基于Kubernetes的容器云平台实战》一书的第10章Kubernetes网络

网络问题。dockernetworkhost是码头网络主机，截止于2022年12月8日dockernetworkhost无法访问localhost的原因就是因为主机的网络问题所导致，在计算机网络中，localhost（意为“本地主机”，指“这台计算机”）是给回路网络接口（loopback）的一个标准主机名。

如上红字所描述：同一个宿主机上的不同容器之间的网络如何互通的？？？

我们安装完docker之后，docker daemon会为我们自动创建3个网络，如下：

其实docker有4种网络通信模型，分别是：bridge、host、none、container

默认的使用的网络模型是bridge，也是我们生产上会使用到的网络模型。

下文中跟大家分享docker容器互通原理到时候呢，用到的也是bridge网络模型

另外，当我们安装完docker之后，docker会为我们创建一个叫docker0的网络设备

通过ifconfig命令可以查看到它，看起来它貌似和eth0网络地位相当，像是一张网卡。然而并不是，docker0其实是一个Linux网桥

何以见得？可以通过下面的命令查看 *** 作系统上的网桥信息

那大家怎么理解Linux网桥的概念呢？

其实大家可以把docker0理解成一台虚拟的交换机！然后像下面这样类比着理解，就会豁然开朗

1、它好比是大学在机房上课时，老师旁边的那个大大的交换机设备。

2、把机房里的电脑都连接在交换机上，类比成docker 容器作为一台设备都连接着宿主机上的docker0。

3、把交换机和机房中的机器的ip在同一个网段，类比成docker0、和你启动的docker容器的ip也同属于172网段。

类比成这样：

我们刚才做类比理解docker0的时候说：把机房里的电脑都连接在交换机上，类比成docker 容器作为一台设备都连接着宿主机上的docker0。那具体的实现落地实现用的是啥技术呢？

答案是：veth pair

veth pair的全称是：virtual ethernet，就是虚拟的以太网卡。

说到以太网卡大家都不陌生呀，不就是我们常见的那种叫eth0或者是ens的网络设备吗？

那这个veth pair是怎么玩的呢？有啥用呢？大家可以看下面这张图

veth-pair设备总是会成对的出现，用于连接两个不同network-namespace

就上图来说，从network-namespace1的veth0中发送的数据会出现在 network-namespace2的veth1设备中。

虽然这种特性很好，但是如果出现有多个容器，你就会发现组织架构会越来越复杂，越来越乱

不过好在我们已经循序渐进的了解Linux网桥（docker0），以及这里的veth-pair设备，于是我们可以把整体的架构图重新绘制成下面这样

因为不同容器有自己隔离后的network-namespace所以他们都有自己的网络协议栈

那我们能不能找到容器里面的网卡和物理机上的哪张卡是一对网络vethpair设备呢？

如下：

回到宿主机

意思是就是说，容器545ed62d3abf的eth0网卡和宿主机通过ip addr命令查看的网络设备标号55的设备组成一对vethpair设备，彼此流量互通！

先看个简单的，同一个局域网中的不同主机A、B之间是如何互联交换数据的。如下图

那，既然是同一个局域网中，说明A、B的ip地址在同一个网段，如上图就假设它们都在19216810网段。

还得再看下面这张OSI 7层网络模型图。

主机A向主机B发送数据，对主机A来说数据会从最上层的应用层一路往下层传递。比如应用层使用的>

以上就是关于docker容器网络全部的内容，包括:docker容器网络、dockernetworkhost无法访问localhost、Docker容器间网络互联原理，讲不明白算我输等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！