容器网络并不难

标签: 容器 网络 | 发表时间:2021-02-17 22:16 | 作者:崔婧雯
出处:http://weekly.dockone.io

【编者的话】本文通过实验方法一步步揭秘容器网络是如何实现容器间的互通,以及容器和外部网络是如何连通的。

使用容器总是感觉像使用魔法一样。对于那些理解底层原理的人来说容器很好用,但是对于不理解的人来说就是个噩梦。很幸运的是,我们已经研究容器技术很久了,甚至成功揭秘 容器只是隔离并受限的Linux进程运行容器并不需要镜像,以及另一个方面, 构建镜像需要运行一些容器
现在是时候解决容器网络问题了。或者更准确地说,单主机容器网络问题。本文会回答这些问题:
  • 如何虚拟化网络资源,让容器认为自己拥有独占网络?
  • 如何让容器们和平共处,之间不会互相干扰,并且能够互相通信?
  • 从容器内部如何访问外部世界(比如,互联网)?
  • 从外部世界如何访问某台机器上的容器呢(比如,端口发布)?


最终结果很明显,单主机容器网络是已知的Linux功能的简单组合:
- 网络命名空间(namespace)
- 虚拟Ethernet设备(veth)
- 虚拟网络交换机(网桥)
- IP路由和网络地址翻译(NAT)
并且不需要任何代码就可以让这样的网络魔法发生....

前提条件

任意Linux发行版都可以。本文的所有例子都是在vagrant CentOS 8的虚拟机上执行的:
$ vagrant init centos/8   
$ vagrant up 
$ vagrant ssh 

[vagrant@localhost ~]$ uname -a 
Linux localhost.localdomain 4.18.0-147.3.1.el8_1.x86_64


为了简单起见,本文使用容器化解决方案(比如,docker或者podman)。我们会重点介绍基本概念,并使用最简单的工具来达到学习目标。

network命名空间隔离容器

Linux网络栈包括哪些部分?显然,是一系列网络设备。还有别的吗?可能还包括一系列的路由规则。并且不要忘记,netfilter hook,包括由iptables规则定义的。

我们可以快速创建一个并不复杂的脚本 inspect-net-stack.sh
  

!/usr/bin/env bash

echo  "> Network devices" 
ip link 

echo -e "\n> Route table" 
ip route 

echo -e "\n> Iptables rules" 
iptables --list-rules

在运行脚本前,让我们修改下iptable rule:
$ sudo iptables -N ROOT_NS  


这之后,在机器上执行上面的脚本,输出如下:
$ sudo ./inspect-net-stack.sh   
> Network devices 
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
2: eth0:  mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff 
> Route table 
default via 10.0.2.2 dev eth0 proto dhcp metric 100 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100 
> Iptables rules 
-P INPUT ACCEPT 
-P FORWARD ACCEPT 
-P OUTPUT ACCEPT 
-N ROOT_NS

我们对这些输出感兴趣,因为要确保即将创建的每个容器都有各自独立的网络栈。
你可能已经知道了,用于容器隔离的一个Linux命名空间是网络命名空间(network namespace)。从 man ip-netns可以看到,“网络命名空间是网络栈逻辑上的另一个副本,它有自己的路由,防火墙规则和网络设备。”为了简化起见,这是本文使用的唯一的命名空间。我们并没有创建完全隔离的容器,而是将范围限制在网络栈上。

创建网络命名空间的一种方法是 ip工具——是 iproute2的一部分:
$ sudo ip netns add netns0   
$ ip netns 
netns0

如何使用刚才创建的命名空间呢?一个很好用的命令 nsenter。进入一个或多个特定的命名空间,然后执行指定的脚本:
$ sudo nsenter --net=/var/run/netns/netns0 bash  
 # 新建的bash进程在netns0里
$ sudo ./inspect-net-stack.sh 
> Network devices 1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
> Route table 
> Iptables rules 
-P INPUT ACCEPT 
-P FORWARD ACCEPT 
-P OUTPUT ACCEPT

从上面的输出可以清楚地看到bash进程运行在 netns0命名空间,这时看到的是完全不同的网络栈。这里没有路由规则,没有自定义的iptables chain,只有一个loopback的网络设备。
enter image description here

使用虚拟的Ethernet设备(veth)将容器连接到主机上

如果我们无法和某个专有的网络栈通信,那么它看上去就没什么用。幸运的是,Linux提供了好用的工具——虚拟Ethernet设备。从 man veth可以看到,“veth设备是虚拟Ethernet设备。他们可以作为网络命名空间之间的通道(tunnel),从而创建连接到另一个命名空间里的物理网络设备的桥梁,但是也可以作为独立的网络设备使用。”

虚拟Ethernet设备通常都成对出现。不用担心,先看一下创建的脚本:
$ sudo ip link add veth0 type veth peer name ceth0  


用这条简单的命令,我们就可以创建一对互联的虚拟Ethernet设备。默认选择了 veth0ceth0这两个名称。
$ ip link   
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
2: eth0:  mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
 link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff 
5: ceth0@veth0:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 
 link/ether 66:2d:24:e3:49:3f brd ff:ff:ff:ff:ff:ff 
6: veth0@ceth0:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 
link/ether 96:e8:de:1d:22:e0 brd ff:ff:ff:ff:ff:ff

创建的 veth0ceth0都在主机的网络栈(也称为root网络命名空间)上。将 netns0命名空间连接到root命名空间,需要将一个设备留在root命名空间,另一个挪到 netns0里:
$ sudo ip link set ceth0 netns netns0   
# 列出所有设备,可以看到ceth0已经从root栈里消失了 
$ ip link 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
2: eth0:  mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 
  link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff 
6: veth0@if5:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 
   link/ether 96:e8:de:1d:22:e0 brd ff:ff:ff:ff:ff:ff link-netns netns0


一旦启用设备并且分配了合适的IP地址,其中一个设备上产生的包会立刻出现在其配对设备里,从而连接起两个命名空间。从root命名空间开始:
$ sudo ip link set veth0 up   
$ sudo ip addr add 172.18.0.11/16 dev veth0

然后是netns0:
$ sudo nsenter --net=/var/run/netns/netns0   
$ ip link set lo up 
$ ip link set ceth0 up 
$ ip addr add 172.18.0.10/16 dev ceth0 
$ ip link 
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 
5: ceth0@if6:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 
link/ether 66:2d:24:e3:49:3f brd ff:ff:ff:ff:ff:ff link-netnsid 0

enter image description here
检查连通性:
# 在netns0里ping root的 veth0   
$ ping -c 2 172.18.0.11 
PING 172.18.0.11 (172.18.0.11) 56(84) bytes of data. 
64 bytes from 172.18.0.11: icmp_seq=1 ttl=64 time=0.038 ms 
64 bytes from 172.18.0.11: icmp_seq=2 ttl=64 time=0.040 ms 
--- 172.18.0.11 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 58ms 
rtt min/avg/max/mdev = 0.038/0.039/0.040/0.001 ms 
 # 离开 netns0
$ exit  
  # 在root命名空间里ping ceth0 
  $ ping -c 2 172.18.0.10 
  PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. 
  64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.073 ms 
  64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.046 ms 
  --- 172.18.0.10 ping statistics --- 
  2 packets transmitted, 2 received, 0% packet loss, time 3ms 
  rtt min/avg/max/mdev = 0.046/0.059/0.073/0.015 ms

同时,如果尝试从 netns0命名空间访问其他地址,也同样可以成功:
# 在 root 命名空间   
$ ip addr show dev eth0 
2: eth0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000 
   link/ether 52:54:00:e3:27:77 brd ff:ff:ff:ff:ff:ff 
   inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0 
    valid_lft 84057sec preferred_lft 84057sec
   inet6 fe80::5054:ff:fee3:2777/64 scope link 
       valid_lft forever preferred_lft forever 
# 记住这里IP是10.0.2.15 
$ sudo nsenter --net=/var/run/netns/netns0 
# 尝试ping主机的eth0 
$ ping 10.0.2.15 
connect: Network is unreachable 
# 尝试连接外网
$ ping 8.8.8.8 
connect: Network is unreachable

这也很好理解。在 netns0路由表里没有这类包的路由。唯一的entry是如何到达 172.18.0.0/16网络:
# 在netns0命名空间:   
$ ip route 
172.18.0.0/16 dev ceth0 proto kernel scope link src 172.18.0.10

Linux有好几种方式建立路由表。其中一种是直接从网络接口上提取路由。记住,命名空间创建后, netns0里的路由表是空的。但是随后我们添加了 ceth0设备并且分配了IP地址 172.18.0.0/16。因为我们使用的不是简单的IP地址,而是地址和子网掩码的组合,网络栈可以从其中提取出路由信息。目的地是 172.18.0.0/16的每个网络包都会通过 ceth0设备。但是其他包会被丢弃。类似的,root命名空间也有了个新的路由:
# 在root命名空间:   
$ ip route 
# ... 忽略无关行 ... 
172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11

这里,就可以回答第一个问题了。我们了解了如何隔离,虚拟化并且连接Linux网络栈。

使用虚拟网络switch(网桥)连接容器

容器化思想的驱动力是高效的资源共享。所以,一台机器上只运行一个容器并不常见。相反,最终目标是尽可能地在共享的环境上运行更多的隔离进程。因此,如果按照上述 veth方案,在同一台主机上放置多个容器的话会发生什么呢?让我们尝试添加第二个容器。
# 从 root 命名空间   
$ sudo ip netns add netns1 
$ sudo ip link add veth1 type veth peer name ceth1 
$ sudo ip link set ceth1 netns netns1 
$ sudo ip link set veth1 up 
$ sudo ip addr add 172.18.0.21/16 dev veth1 
$ sudo nsenter --net=/var/run/netns/netns1 
$ ip link set lo up 
$ ip link set ceth1 up 
$ ip addr add 172.18.0.20/16 dev ceth1

检查连通性:
# 从netns1无法连通root 命名空间!   
$ ping -c 2 172.18.0.21 
PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data. 
From 172.18.0.20 icmp_seq=1 Destination Host Unreachable 
From 172.18.0.20 icmp_seq=2 Destination Host Unreachable 
--- 172.18.0.21 ping statistics --- 
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 55ms pipe 2 
# 但是路由是存在的! 
$ ip route 
172.18.0.0/16 dev ceth1 proto kernel scope link src 172.18.0.20 
# 离开 `netns1` 
$ exit  
# 从 root 命名空间无法连通`netns1` 
$ ping -c 2 172.18.0.20 
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 
From 172.18.0.11 icmp_seq=1 Destination Host Unreachable 
From 172.18.0.11 icmp_seq=2 Destination Host Unreachable 

--- 172.18.0.20 ping statistics --- 
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 23ms pipe 2 
# 从netns0可以连通`veth1` 
$ sudo nsenter --net=/var/run/netns/netns0 
$ ping -c 2 172.18.0.21 
PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data. 
64 bytes from 172.18.0.21: icmp_seq=1 ttl=64 time=0.037 ms 
64 bytes from 172.18.0.21: icmp_seq=2 ttl=64 time=0.046 ms 
--- 172.18.0.21 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 33ms 
rtt min/avg/max/mdev = 0.037/0.041/0.046/0.007 ms 
# 但是仍然无法连通netns1 
$ ping -c 2 172.18.0.20 
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 
From 172.18.0.10 icmp_seq=1 Destination Host Unreachable 
From 172.18.0.10 icmp_seq=2 Destination Host Unreachable 
--- 172.18.0.20 ping statistics --- 
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 63ms pipe 2


晕!有地方出错了... netns1有问题。它无法连接到root,并且从root命名空间里也无法访问到它。但是,因为两个容器都在相同的IP网段 172.18.0.0/16里,从 netns0容器可以访问到主机的 veth1

这里花了些时间来找到原因,不过很明显遇到的是路由问题。先查一下root命名空间的路由表:
$ ip route   
# ... 忽略无关行... # 
172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11 
172.18.0.0/16 dev veth1 proto kernel scope link src 172.18.0.21

在添加了第二个 veth对之后,root的网络栈知道了新路由 172.18.0.0/16 dev veth1 proto kernel scope link src 172.18.0.21,但是之前已经存在该网络的路由了。当第二个容器尝试ping veth1时,选中的是第一个路由规则,这导致网络无法连通。如果我们删除第一个路由 sudo ip route delete 172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11,然后重新检查连通性,应该就没有问题了。 netns1可以连通,但是 netns0就不行了。
enter image description here
如果我们为 netns1选择其他的网段,应该就都可以连通。但是,多个容器在同一个IP网段上应该是合理的使用场景。因此,我们需要调整 veth方案。

别忘了还有Linux网桥——另一种虚拟化网络技术!Linux网桥作用类似于网络switch。它会在连接到其上的接口间转发网络包。并且因为它是switch,它是在L2层完成这些转发的。

试试这个工具。但是首先,需要清除已有设置,因为之前的一些配置现在不再需要了。删除网络命名空间:
$ sudo ip netns delete netns0   
$ sudo ip netns delete netns1 
$ sudo ip link delete veth0 
$ sudo ip link delete ceth0 
$ sudo ip link delete veth1 
$ sudo ip link delete ceth1


快速重建两个容器。注意,我们没有给新的 veth0veth1设备分配任何IP地址:
$ sudo ip netns add netns0   
$ sudo ip link add veth0 type veth peer name ceth0 
$ sudo ip link set veth0 up 
$ sudo ip link set ceth0 netns netns0 

$ sudo nsenter --net=/var/run/netns/netns0 
$ ip link set lo up 
$ ip link set ceth0 up 
$ ip addr add 172.18.0.10/16 dev ceth0 
$ exit 

$ sudo ip netns add netns1 
$ sudo ip link add veth1 type veth peer name ceth1 
$ sudo ip link set veth1 up 
$ sudo ip link set ceth1 netns netns1 

$ sudo nsenter --net=/var/run/netns/netns1 
$ ip link set lo up 
$ ip link set ceth1 up 
$ ip addr add 172.18.0.20/16 dev ceth1 
$ exit

确保主机上没有新的路由:
$ ip route   
default via 10.0.2.2 dev eth0 proto dhcp metric 100 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100


最后创建网桥接口:
$ sudo ip link add br0 type bridge   
$ sudo ip link set br0 up

veth0veth1接到网桥上:
$ sudo ip link set veth0 master br0   
$ sudo ip link set veth1 master br0

enter image description here
检查容器间的连通性:
$ sudo nsenter --net=/var/run/netns/netns0   
$ ping -c 2 172.18.0.20 
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 
64 bytes from 172.18.0.20: icmp_seq=1 ttl=64 time=0.259 ms 
64 bytes from 172.18.0.20: icmp_seq=2 ttl=64 time=0.051 ms 
--- 172.18.0.20 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 2ms 
rtt min/avg/max/mdev = 0.051/0.155/0.259/0.104 ms

$ sudo nsenter --net=/var/run/netns/netns1   
$ ping -c 2 172.18.0.10 
PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. 
64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.037 ms 
64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.089 ms 
--- 172.18.0.10 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 36ms 
rtt min/avg/max/mdev = 0.037/0.063/0.089/0.026 ms


太好了!工作得很好。用这种新方案,我们根本不需要配置 veth0veth1。只需要在 ceth0ceth1端点分配两个IP地址。但是因为它们都连接在相同的Ethernet上(记住,它们连接到虚拟switch上),之间在L2层是连通的:
$ sudo nsenter --net=/var/run/netns/netns0   
$ ip neigh 
172.18.0.20 dev ceth0 lladdr 6e:9c:ae:02:60:de STALE 
$ exit 

$ sudo nsenter --net=/var/run/netns/netns1 
$ ip neigh 
172.18.0.10 dev ceth1 lladdr 66:f3:8c:75:09:29 STALE 
$ exit

太好了,我们学习了如何将容器变成友邻,让它们互不干扰,但是又可以连通。

连接外部世界(IP路由和地址伪装(masquerading))

容器间可以通信。但是它们能和主机,比如root命名空间,通信吗?
$ sudo nsenter --net=/var/run/netns/netns0   
$ ping 10.0.2.15 # eth0 address 
connect: Network is unreachable


这里很明显, netns0没有路由:
$ ip route   
172.18.0.0/16 dev ceth0 proto kernel scope link src 172.18.0.10

root命名空间不能和容器通信:
# 首先使用 exit 离开netns0:   
$ ping -c 2 172.18.0.10 
PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. 
From 213.51.1.123 icmp_seq=1 Destination Net Unreachable 
From 213.51.1.123 icmp_seq=2 Destination Net Unreachable 
--- 172.18.0.10 ping statistics --- 
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms 

$ ping -c 2 172.18.0.20 
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 
From 213.51.1.123 icmp_seq=1 Destination Net Unreachable 
From 213.51.1.123 icmp_seq=2 Destination Net Unreachable 
--- 172.18.0.20 ping statistics --- 
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 3ms


要建立root和容器命名空间的连通性,我们需要给网桥网络接口分配IP地址:
$ sudo ip addr add 172.18.0.1/16 dev br0  


一旦给网桥网络接口分配了IP地址,在主机的路由表里就会多一条路由:
$ ip route   
# ...忽略无关行 ... 
172.18.0.0/16 dev br0 proto kernel scope link src 172.18.0.1 

$ ping -c 2 172.18.0.10 
PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. 
64 bytes from 172.18.0.10: icmp_seq=1 ttl=64 time=0.036 ms 
64 bytes from 172.18.0.10: icmp_seq=2 ttl=64 time=0.049 ms 

--- 172.18.0.10 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 11ms 
rtt min/avg/max/mdev = 0.036/0.042/0.049/0.009 ms 

$ ping -c 2 172.18.0.20 
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 
64 bytes from 172.18.0.20: icmp_seq=1 ttl=64 time=0.059 ms 
64 bytes from 172.18.0.20: icmp_seq=2 ttl=64 time=0.056 ms 

--- 172.18.0.20 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 4ms 
rtt min/avg/max/mdev = 0.056/0.057/0.059/0.007 ms


容器可能也可以ping网桥接口,但是它们还是无法连接到主机的 eth0。需要为容器添加默认的路由:
$ sudo nsenter --net=/var/run/netns/netns0   
$ ip route add default via 172.18.0.1 
$ ping -c 2 10.0.2.15 
PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data. 
64 bytes from 10.0.2.15: icmp_seq=1 ttl=64 time=0.036 ms 
64 bytes from 10.0.2.15: icmp_seq=2 ttl=64 time=0.053 ms 
--- 10.0.2.15 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 14ms 
rtt min/avg/max/mdev = 0.036/0.044/0.053/0.010 ms 
# 为`netns1`也做上述配置

这个改动基本上把主机变成了路由,并且网桥接口变成了容器间的默认网关。
enter image description here
很好,我们将容器连接到root命名空间上。现在,继续尝试将它们连接到外部世界。Linux上默认disable了网络包转发(比如,路由功能)。我们需要先启用这个功能:
# 在 root 命名空间   
sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

再次检查连通性:
$ sudo nsenter --net=/var/run/netns/netns0   
$ ping 8.8.8.8 
# hung住了...

还是不工作。哪里弄错了呢?如果容器可以向外部发包,那么目标服务器无法将包发回容器,因为容器的IP地址是私有的,那个特定IP的路由规则只有本地网络知道。并且有很多容器共享的是完全相同的私有IP地址 172.18.0.10。这个问题的解决方法称为 网络地址翻译(NAT)。在到达外部网络之前,容器发出的包会将源IP地址替换为主机的外部网络地址。主机还会跟踪所有已有的映射,会在将包转发回容器之前恢复之前被替换的IP地址。听上去很复杂,但是有一个好消息! iptables模块让我们只需要一条命令就可以完成这一切:
$ sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE  


命令非常简单。在 nat表里添加了一条 POSTROUTING chain的新路由,会替换伪装所有源于 172.18.0.0/16网络的包,但是不通过网桥接口。
检查连通性:
$ sudo nsenter --net=/var/run/netns/netns0   
$ ping -c 2 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=43.2 ms 
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=36.8 ms 
--- 8.8.8.8 ping statistics --- 
2 packets transmitted, 2 received, 0% packet loss, time 2ms 
rtt min/avg/max/mdev = 36.815/40.008/43.202/3.199 ms

要知道这里我们用的默认策略——允许所有流量,这在真实的环境里是非常危险的。主机的默认iptables策略是 ACCEPT
sudo iptables -S   
-P INPUT ACCEPT 
-P FORWARD ACCEPT 
-P OUTPUT ACCEPT

Docker默认限制所有流量,随后仅仅为已知的路径启用路由。
如下是在CentOS 8机器上,单个容器暴露了端口5005时,由Docker daemon生成的规则:
$ sudo iptables -t filter --list-rules   
-P INPUT ACCEPT 
-P FORWARD DROP 
-P OUTPUT ACCEPT 
-N DOCKER 
-N DOCKER-ISOLATION-STAGE-1 
-N DOCKER-ISOLATION-STAGE-2 
-N DOCKER-USER 
-A FORWARD -j DOCKER-USER 
-A FORWARD -j DOCKER-ISOLATION-STAGE-1 
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER 
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT 
-A FORWARD -i docker0 -o docker0 -j ACCEPT 
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 5000 -j ACCEPT 
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2 
-A DOCKER-ISOLATION-STAGE-1 -j RETURN 
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP 
-A DOCKER-ISOLATION-STAGE-2 -j RETURN 
-A DOCKER-USER -j RETURN 

$ sudo iptables -t nat --list-rules 
-P PREROUTING ACCEPT 
-P INPUT ACCEPT 
-P POSTROUTING ACCEPT 
-P OUTPUT ACCEPT 
-N DOCKER 
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER 
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE 
-A POSTROUTING -s 172.17.0.2/32 -d 172.17.0.2/32 -p tcp -m tcp --dport 5000 -j MASQUERADE
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER 
-A DOCKER -i docker0 -j RETURN 
-A DOCKER ! -i docker0 -p tcp -m tcp --dport 5005 -j DNAT --to-destination 172.17.0.2:5000 

$ sudo iptables -t mangle --list-rules 
-P PREROUTING ACCEPT 
-P INPUT ACCEPT 
-P FORWARD ACCEPT 
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT 

$ sudo iptables -t raw --list-rules 
-P PREROUTING ACCEPT 
-P OUTPUT ACCEPT


让外部世界可以访问容器(端口发布)

大家都知道可以将容器端口发布给一些(或者所有)主机的接口。但是端口发布到底是什么意思呢?
假设容器内运行着服务器:
$ sudo nsenter --net=/var/run/netns/netns0   
$ python3 -m http.server --bind 172.18.0.10 5000

如果我们试着从主机上发送一个HTTP请求到这个服务器,一切都工作得很好(root命名空间和所有容器接口之间有链接,当然可以连接成功):
# 从 root 命名空间   
$ curl 172.18.0.10:5000 
 
# ... 忽略无关行 ...

但是,如果要从外部访问这个服务器,应该使用哪个IP呢?我们知道的唯一IP是主机的外部接口地址 eth0
$ curl 10.0.2.15:5000   
curl: (7) Failed to connect to 10.0.2.15 port 5000: Connection refused


因此,我们需要找到方法,能够将到达主机 eth05000端口的所有包转发到目的地 172.18.0.10:5000。又是iptables来帮忙!
# 外部流量    
sudo iptables -t nat -A PREROUTING -d 10.0.2.15 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000 
# 本地流量 (因为它没有通过 PREROUTING chain) 
sudo iptables -t nat -A OUTPUT -d 10.0.2.15 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000

另外,需要让 iptables能够在桥接网络上截获流量
sudo modprobe br_netfilter  

测试:
curl 10.0.2.15:5000   

  # ... 忽略无关行 ...

理解Docker网络驱动

我们可以怎么使用这些知识呢?比如,可以试着理解 Docker网络模式
--network host模式开始。试着比较一下命令 ip linksudo docker run -it --rm --network host alpine ip link的输出。它们几乎一样!在 host模式下,Docker简单地没有使用网络命名空间隔离,容器就在root网络命名空间里工作,并且和主机共享网络栈。

下一个模式是 --network nonesudo docker run -it --rm --network host alpine ip link的输出只有一个loopback网络接口。这和之前创建的网络命名空间,没有添加 veth设备前很相似。

最后是 --network bridge(默认)模式。这正是我们前文尝试创建的模式。大家可以试试 ipiptables命令,分别从主机和容器的角度观察一下网络栈。

rootless容器和网络

podman容器管理器的一个很好的特性是关注于rootless容器。但是,你可能注意到,本文使用了很多 sudo命令。说明,没有root权限无法配置网络。 Podman在root网络上的方案和docker非常相似。但是在rootless容器上,podman使用了 slirp4netns项目:

从Linux 3.8开始,非特权用户可以创建user_namespaces(7)的同时创建network_namespaces(7)。但是,非特权网络命名空间并不是很有用,因为在主机和网络命名空间之间创建veth(4)仍然需要root权限
slirp4netns可以用完全非特权的方式将网络命名空间连接到Internet上,通过网络命名空间里的一个TAP设备连接到用户态的TCP/IP栈(slirp)。
rootless网络是很有限的:“从技术上说,容器本身没有IP地址,因为没有root权限,无法实现网络设备的关联。另外,从rootless容器ping是不会工作的,因为它缺少CAP_NET_RAW安全能力,而这是ping命令必需的。”但是它仍然比完全没有连接要好。

结论

本文介绍的组织容器网络的方案仅仅是可能方案的一种(可能是最为广泛使用的一种)。还有很多别的方式,由官方或者第三方插件实现,但是所有这些方案都严重依赖于 Linux网络虚拟化技术。因此,容器化可以认为是一种虚拟化技术。

参考文献



相关文章



原文链接: Container networking is simple(翻译:崔婧雯 )
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

相关 [容器 网络] 推荐:

容器网络并不难

- - DockOne.io
【编者的话】本文通过实验方法一步步揭秘容器网络是如何实现容器间的互通,以及容器和外部网络是如何连通的. 使用容器总是感觉像使用魔法一样. 对于那些理解底层原理的人来说容器很好用,但是对于不理解的人来说就是个噩梦. 很幸运的是,我们已经研究容器技术很久了,甚至成功揭秘 容器只是隔离并受限的Linux进程, 运行容器并不需要镜像,以及另一个方面, 构建镜像需要运行一些容器.

聊聊容器网络和 iptables

- - MoeLove
上周有小伙伴在群里问到 Docker 和 Iptables 的关系,这里来具体聊聊. Docker 能为我们提供很强大和灵活的网络能力,很大程度上要归功于与 iptables 的结合. 在使用时,你可能没有太关注到 iptables 的作用,这是因为 Docker 已经帮我们自动完成了相关的配置. docker daemon 有个 --iptables 的参数,便是用来控制是否要自动启用 iptables 规则的,默认已经设置成了开启(true).

理解Docker跨多主机容器网络

- - Tony Bai
在 Docker 1.9 出世前,跨多主机的容器通信方案大致有如下三种:. 将宿主机A的端口P映射到容器C的网络空间监听的端口P’上,仅提供四层及以上应用和服务使用. 这样其他主机上的容器通过访问宿主机A的端口P实 现与容器C的通信. 显然这个方案的应用场景很有局限. 2、将物理网卡桥接到虚拟网桥,使得容器与宿主机配置在同一网段下.

K8S的SDN容器网络解决方案及其价值

- - SegmentFault 最新的文章
编者按:关于容器网络的解决方案业界已经有较多的讨论,笔者无意继续赘述. K8S及其网络模型体现了鲜明的解耦设计思想,采用SDN技术实现K8S容器网络,并与相应的生态组件形成SDN监管控一体化解决方案,可以更好地提高整个系统的运营水平,更有效地提升企业的核心竞争力. 本文拟抛砖引玉,从K8S的网络实现入手,重点阐述SDN在容器网络中的应用价值.

Kubernetes容器网络及Flannel插件详解

- - 掘金 后端
这是我参与「掘金日新计划 · 6 月更文挑战」的第2天, 点击查看活动详情. Kubernetes是一个开源容器调度编排引擎,管理大规模容器化应用,采用典型的Master-Worker主从分布式技术架构,由集中式管理节点(Master Node),分布式的工作节点(Worker Node)组成. 向下屏蔽底层差异化的分布式基础设施,以应用为中心构建云计算的基础操作系统能力(即云原生操作系统),面向用户提供云原生时代的云计算的新界面.

网络

- 火锅土豆 - 科学松鼠会
本文地址(转载请注明出处): 复制.

网络爬虫

- - 四火的唠叨
文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》. 最近在写一个程序,去爬热门事件和热门关键词网站上的数据. 网络爬虫也叫做网络蜘蛛,是一种互联网机器人,把需要的网页撷取下来,组织成适当格式存储. 它是搜索引擎的重要组成部分,虽然从技术实现上来说,它的难度往往要小于对于得到的网页信息的处理.

网络安全

- - CSDN博客系统运维推荐文章
1、防止入侵者对主机进行ping探测,可以禁止Linux主机对ICMP包的回应.  iptables 防火墙上禁止ICMP应答.  关闭不必要的端口,时常检查网络端口情况.  nmap  可以扫描端口.  关闭不必要的服务和端口.  为网络服务指定非标准的端口.  开启防火墙,只允许授权用户访问相应的服务端口.

Java中的CopyOnWrite容器

- - 酷 壳 - CoolShell.cn
感谢  清英 同学的投稿. Copy-On-Write简称COW,是一种用于程序设计中的优化策略. 其基本思路是,从一开始大家都在共享同一个内容,当某个人想要修改这个内容的时候,才会真正把内容Copy出去形成一个新的内容然后再改,这是一种延时懒惰策略. 从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,它们是CopyOnWriteArrayList和CopyOnWriteArraySet.

有赞容器化实践

- - SegmentFault 最新的文章
容器化已经成为一种趋势,它可以解决很多运维中的痛点,比如效率、成本、稳定性等问题,而接入容器的过程中往往也会碰到很多问题和不便. 在有赞最开始做容器化是为了快速交付开发测试环境,在容器化的过程中,我们碰到过容器技术、运维体系适配、用户使用习惯改变等各种问题,本文主要介绍有赞容器化过程中碰到的问题以及采取的方案.