解密Docker容器网络

简介: 解密Docker容器网络

一个Linux容器能看见的“网络栈”,被隔离在它自己的Network Namespace中。

1 “网络栈”的内容

  • 网卡(Network Interface)
  • 回环设备(Loopback Device)
  • 路由表(Routing Table)
  • iptables规则

对于一个进程,这些构成它发起、响应网络请求的基本环境。

作为一个容器,它可声明直接使用宿主机的网络栈(–net=host),即不开启Network Namespace,如:

$ docker run –d –net=host --name nginx-host nginx

这容器启动后,直接监听的就是宿主机80端口。


这种直接使用宿主机网络栈,虽可为容器提供良好网络性能,但也引入共享网络资源问题,如端口冲突。所以,大多情况下,都希望容器进程能使用自己Network Namespace里的网络栈,即拥有属于自己的IP地址和端口。


但这被隔离的容器进程,如何和其他Network Namespace里的容器进程交互?


可将每个容器看做一台主机,它们都有一套独立“网络栈”:

  • 若想要实现两台主机之间的通信,最直接的就是把它们用一根网线连接
  • 若你想实现多台主机之间的通信,就需要用网线,把它们连接在一台交换机

Linux中起到虚拟交换机作用的网络设备,是网桥(Bridge),工作在数据链路层(Data Link)的设备,根据MAC地址学习来将数据包转发到网桥的不同端口(Port)。


为何这些主机间需MAC地址才能进行通信,这就是网络分层模型的基础知识。这篇文章。


为实现上述目的,Docker会默认在宿主机创建一个docker0网桥,凡是连接在docker0网桥上的容器,就可通过它进行通信。

如何把这些容器“连接”到docker0网桥?

需要使用一种名叫Veth Pair的虚拟设备。

Veth Pair设备特点

它被创建出来后,总以两张虚拟网卡(Veth Peer)形式成对出现。且从其中一个“网卡”发出的数据包,可直接出现在与它对应的另一张“网卡”,哪怕这两个“网卡”在不同Network Namespace。


这使Veth Pair常被用作连接不同Network Namespace 的“网线”。


启动nginx-1容器:

$ docker run –d --name nginx-1 nginx

进入容器,查看其网络设备:

# 在宿主机上
$ docker exec -it nginx-1 /bin/bash
# 在容器里
root@2b3c181aecf1:/# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.2  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::42:acff:fe11:2  prefixlen 64  scopeid 0x20<link>
        ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)
        RX packets 364  bytes 8137175 (7.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 281  bytes 21161 (20.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0

可这容器里有张eth0网卡,正是一个Veth Pair设备在容器里的这端。


通过route命令查看nginx-1容器的路由表,可见,这eth0网卡是这容器里的默认路由设备;所有对172.17.0.0/16网段的请求,也会被交给eth0处理(第二条172.17.0.0路由规则)。


而这Veth Pair设备的另一端,则在宿主机。可通过查看宿主机的网络设备看到它:

# 在宿主机上
$ ifconfig
...
docker0   Link encap:Ethernet  HWaddr 02:42:d8:e4:df:c1  
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:d8ff:fee4:dfc1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:309 errors:0 dropped:0 overruns:0 frame:0
          TX packets:372 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0 
          RX bytes:18944 (18.9 KB)  TX bytes:8137789 (8.1 MB)
veth9c02e56 Link encap:Ethernet  HWaddr 52:81:0b:24:3d:da  
          inet6 addr: fe80::5081:bff:fe24:3dda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:288 errors:0 dropped:0 overruns:0 frame:0
          TX packets:371 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0 
          RX bytes:21608 (21.6 KB)  TX bytes:8137719 (8.1 MB)
$ brctl show
bridge name bridge id  STP enabled interfaces
docker0  8000.0242d8e4dfc1 no  veth9c02e56

可这容器里有张eth0网卡,正是一个Veth Pair设备在容器里的这端。


通过route命令查看nginx-1容器的路由表,可见,这eth0网卡是这容器里的默认路由设备;所有对172.17.0.0/16网段的请求,也会被交给eth0处理(第二条172.17.0.0路由规则)。


而这Veth Pair设备的另一端,则在宿主机。可通过查看宿主机的网络设备看到它:

# 在宿主机上
$ ifconfig
...
docker0   Link encap:Ethernet  HWaddr 02:42:d8:e4:df:c1  
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::42:d8ff:fee4:dfc1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:309 errors:0 dropped:0 overruns:0 frame:0
          TX packets:372 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0 
          RX bytes:18944 (18.9 KB)  TX bytes:8137789 (8.1 MB)
veth9c02e56 Link encap:Ethernet  HWaddr 52:81:0b:24:3d:da  
          inet6 addr: fe80::5081:bff:fe24:3dda/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:288 errors:0 dropped:0 overruns:0 frame:0
          TX packets:371 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0 
          RX bytes:21608 (21.6 KB)  TX bytes:8137719 (8.1 MB)
$ brctl show
bridge name bridge id  STP enabled interfaces
docker0  8000.0242d8e4dfc1 no  veth9c02e56

nginx-1容器对应的Veth Pair设备,在宿主机上是张虚拟网卡-veth9c02e56。通过brctl show的输出,可见这张网卡被“插”在docker0。

这时候,如再在这台宿主机上启动另一个Docker容器,如nginx-2:

$ docker run –d --name nginx-2 nginx
$ brctl show
bridge name bridge id  STP enabled interfaces
docker0  8000.0242d8e4dfc1 no  veth9c02e56
       vethb4963f3

就会发现新的、名叫vethb4963f3的虚拟网卡,也被“插”在docker0网桥。

这时候,若你在nginx-1容器ping一下nginx-2容器的IP地址(172.17.0.3),就会发现同一宿主机上的两个容器默认相互连通。

同一宿主机的容器默认相互连通的原理

在nginx-1容器访问nginx-2容器IP地址(如ping 172.17.0.3)时,这目的IP地址会匹配到nginx-1容器里的第二条路由规则。可见,这条路由规则的网关(Gateway)是0.0.0.0,即这是一条直连规则,凡是匹配到这条规则的IP包,应经过本机的eth0网卡,通过二层网络直接发往目的主机。


要通过二层网络到达nginx-2容器,就要有172.17.0.3 IP地址对应的MAC地址。所以nginx-1容器的网络协议栈,就需要通过eth0网卡发送一个ARP广播,来通过IP地址查找对应的MAC地址。

ARP(Address Resolution Protocol),通过三层的IP地址找到对应的二层MAC地址的协议。

我们前面提到过,这个eth0网卡,是一个Veth Pair,它的一端在这个nginx-1容器的Network Namespace里,而另一端则位于宿主机上(Host Namespace),并且被“插”在了宿主机的docker0网桥上。


一旦一张虚拟网卡被“插”在网桥,它就会变成该网桥的“从设备”。从设备会被“剥夺”调用网络协议栈处理数据包的资格,“降级”成网桥上的一个端口。这端口唯一作用:接收流入的数据包,然后把这些数据包的“生杀大权”(如转发或丢弃),全部交给对应网桥。

所以,收到这些ARP请求后,docker0网桥就会扮演二层交换机,把ARP广播转发到其他被“插”在docker0上的虚拟网卡上。这样,同样连接在docker0上的nginx-2容器的网络协议栈就会收到这个ARP请求,从而将172.17.0.3所对应的MAC地址回复给nginx-1容器。


有这目的MAC地址,nginx-1容器的eth0网卡就可将数据包发出去。


根据Veth Pair设备原理,这数据包会立刻出现在宿主机上的veth9c02e56虚拟网卡。不过,此时这veth9c02e56网卡的网络协议栈资格已被“剥夺”,所以这数据包就直接流入到docker0网桥。


docker0处理转发的过程,则继续扮演二层交换机的角色。此时,docker0网桥根据数据包的目的MAC地址(即nginx-2容器的MAC地址),在其CAM表(即交换机通过MAC地址学习维护的端口和MAC地址的对应表)里查到对应端口为:vethb4963f3,然后把数据包发往这端口。


这端口正是nginx-2容器“插”在docker0网桥的另一块虚拟网卡,也是个Veth Pair设备。这样,数据包就进入了nginx-2容器的Network Namespace。


所以,nginx-2容器看到它自己的eth0网卡出现了流入的数据包。这样,nginx-2的网络协议栈就会对请求进行处理,最后将响应(Pong)返回到nginx-1。


这就是同一宿主机的不同容器通过docker0网桥进行通信的流程:

实际数据传递时,上述数据的传递过程在网络协议栈的不同层次,都有Linux内核Netfilter参与。可通过打开iptables的TRACE功能查看到数据包传输过程:

# 在宿主机上执行
$ iptables -t raw -A OUTPUT -p icmp -j TRACE
$ iptables -t raw -A PREROUTING -p icmp -j TRACE

就可在/var/log/syslog里看到数据包传输的日志。iptables的相关知识进行实践,验证数据包传递流程。


默认情况下,被限制在Network Namespace里的容器进程,就是通过Veth Pair设备+宿主机网桥,实现同其他容器的数据交换。


类似地,当你在一台宿主机,访问该宿主机上的容器的IP地址时,这请求的数据包,也是先根据路由规则到达docker0网桥,然后被转发到对应Veth Pair设备,最后出现在容器:

接下来,这数据包就会经宿主机的eth0网卡转发到宿主机网络,最终到达10.168.0.3对应宿主机。这过程要求这两台宿主机本身连通:

在最后一个“Docker容器连接其他宿主机”案例,你可能联想到:若在另一宿主机(如:10.168.0.3)也有一个Docker容器。我们的nginx-1容器又该如何访问它?

容器的“跨主通信”问题

Docker默认配置下,一台宿主机上的docker0网桥,和其他宿主机上的docker0网桥无任何关联,互相无法连通。所以,连接在这些网桥的容器,自然也无法通信,咋办呢?


若通过软件创建一个整个集群“公用”的网桥,再把集群里的所有容器都连接到这网桥,不就能相互通信?


这样,整个集群里的容器网络就类似:

构建这种容器网络的核心:要在已有的宿主机网络,再通过软件构建一个覆盖在已有宿主机网络之上的、可将所有容器连通在一起的虚拟网络。所以,这技术称为:Overlay Network(覆盖网络)。


而这Overlay Network本身,可由每台宿主机上的一个“特殊网桥”共同组成。如当Node 1上的Container 1要访问Node 2上的Container 3时,Node 1上的“特殊网桥”在收到数据包后,能通过某种方式,把数据包发到正确宿主机,如Node 2。


而Node 2上的“特殊网桥”收到数据包后,也能通过某种方式,把数据包转发给正确容器,如Container 3。


甚至,每台宿主机上,都无需这种特殊网桥,而仅通过某种方式配置宿主机的路由表,就能把数据包转发到正确宿主机。

总结

本地环境下,单机容器网络的实现原理和docker0网桥的作用。

容器想跟外界通信,它发出的IP包须从它的Network Namespace里出来,来到宿主机。

解决这问题的方法:为容器创建一个一端在容器里充当默认网卡、另一端在宿主机上的Veth Pair设备。

FAQ

尽管容器的Host Network模式有缺点,但性能好、配置简单,并且易于调试,所以很多团队会直接使用Host Network。要在生产环境中使用容器的Host Network模式,做哪些额外准备工作?

  • 限制容器使用的端口范围围,避免与主机上的其他服务冲突
  • 部署网络安全措施,如防火墙和访问控制列表,以保护主机和容器之间的通信
  • 配置适当的监控和日志记录,以便及时发现和解决问题
  • 对主机进行安全加固,以避免容器之间或容器与主机之间的攻击
  • 对主机进行性能测试,以确保它能够承受额外的负载,并且不会影响其他服务的性能
目录
相关文章
|
10天前
|
Kubernetes Cloud Native Docker
云原生时代的容器化实践:Docker和Kubernetes入门
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术成为企业提升敏捷性和效率的关键。本篇文章将引导读者了解如何利用Docker进行容器化打包及部署,以及Kubernetes集群管理的基础操作,帮助初学者快速入门云原生的世界。通过实际案例分析,我们将深入探讨这些技术在现代IT架构中的应用与影响。
42 2
|
8天前
|
运维 Cloud Native 虚拟化
一文吃透云原生 Docker 容器,建议收藏!
本文深入解析云原生Docker容器技术,涵盖容器与Docker的概念、优势、架构设计及应用场景等,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
一文吃透云原生 Docker 容器,建议收藏!
|
4天前
|
运维 Cloud Native 云计算
云原生之旅:Docker容器化实战
本文将带你走进云原生的世界,深入理解Docker技术如何改变应用部署与运维。我们将通过实际案例,展示如何利用Docker简化开发流程,提升应用的可移植性和伸缩性。文章不仅介绍基础概念,还提供操作指南和最佳实践,帮助你快速上手Docker,开启云原生的第一步。
|
2天前
|
关系型数据库 MySQL Java
【Docker最新版教程】一文带你快速入门Docker常见用法,实现容器编排和自动化部署上线项目
Docker快速入门到项目部署,MySQL部署+Nginx部署+docker自定义镜像+docker网络+DockerCompose项目实战一文搞定!
|
1天前
|
开发者 Docker Python
从零开始:使用Docker容器化你的Python Web应用
从零开始:使用Docker容器化你的Python Web应用
8 1
|
5天前
|
运维 持续交付 虚拟化
深入解析Docker容器化技术的核心原理
深入解析Docker容器化技术的核心原理
22 1
|
7天前
|
机器学习/深度学习 数据采集 Docker
Docker容器化实战:构建并部署一个简单的Web应用
Docker容器化实战:构建并部署一个简单的Web应用
|
7天前
|
JavaScript 开发者 Docker
Docker容器化实战:构建并部署一个简单的Web应用
Docker容器化实战:构建并部署一个简单的Web应用
|
7天前
|
持续交付 开发者 Docker
Docker容器化技术实战指南
Docker容器化技术实战指南
23 1
|
7天前
|
安全 Docker 微服务
深入理解Docker容器技术:从基础到实践
深入理解Docker容器技术:从基础到实践

热门文章

最新文章

下一篇
无影云桌面