为什么隧道封装是Docker多数网络项目的共同选择

406次阅读

共计 1977 个字符，预计需要花费 5 分钟才能阅读完成。

背景

在我之前 weave 的运行原理的文章中，介绍到 weave 在跨主机的容器通信过程中，会使用 pcap 截获容器发送和接收的网络包，然后按照自定义的格式将这些包重新封装为 UDP 报文再次注入到 bridge 上的接口发送出去。实际上这不是 weave 独有的选择，CoreOS 的 fannel 网络项目也是一样的方法。最近被 docker 公司收购的初创项目 socketplane，采用基于 openvswitch 的 vxlan 的隧道技术来实现相同的过程。那么，就有一个疑问：实际上只要使用主机 port mapping 或是将 docker 原生网桥 docker0 的上行链路连通网卡，容器的流量都可以从主机发送出去，为什么这么多的 docker 网络项目都不约而同地选择使用隧道技术将网络负载再次封装发送，接收的时候再解封装呢？

解析原因

隧道封装是目前最简单的穿透 docker 容器复杂网络环境安全设置的方法

实际上这个问题最重要的原因是与 docker 容器运行环境的多样复杂性是直接相关的。我们都知道 docker 容器可以运行在公有云、私有云、虚拟化以及裸机上。为了网络的安全，这些环境上都应该有严格的安全组和防火墙设置来保障只有合法流量能够通过端口。这些带来了网络安全的同时，也给 docker 容器的部署和可移动性带来了麻烦。每次部署启动一个容器，就要将其相应使用的端口上的安全设置更新为开放。尤其是混合云场景下这个问题就更为麻烦了。我举一个具体的例子：当前很多的 PaaS 服务提供商都没有自己的数据中心，他们直接从公有云的 IaaS 提供商那里获得虚拟机，那么这个时候就需要 PaaS 提供方调用公有云 IaaS 提供方的网络安全设置的 API 来打开端口。PaaS 提供商是不会把自己绑定死的，会选择多家公有云的 IaaS（AWS，GCE，Azure 等），这些 IaaS 提供商的 API 全都不一样，这得多麻烦啊。这还没有考虑私有云，自己数据中心的虚拟化和裸机环境的端口 ACL 设置的复杂。

网络安全的设置还不仅仅只有这些，比如最常见的 ip 与 mac 绑定，这是 openstack 的默认设置，要修改可以，同样也要调用 openstack neutron 的 API 增加端口允许的 ip-mac pair。这里额外提一下，docker 主机的 port mapping 方式由于限制了容器移动后的可访问性，不被大多数跨主机 docker 网络项目采用，多数项目还是希望能给每个容器一个 ip，容器间访问使用这个 ip，而不是 docker 容器所在主机的 ip。

结论

通过上面的解析，可以想象，如果是在混合云场景下，使用隧道封装技术后，从虚拟机流出的流量 ip 和 mac 都是唯一的，且只使用固定的端口，那 docker 容器运行环境的安全设置就可以固定下来，简便多了。

其实，docker 网络中使用隧道封装技术还可以有利于一些其他问题的解决：

1. 容器相较于虚拟机在一台主机上的密度大大增加，至少多出一个量级，要说两个量级我也信。在这样的情况下机架上的接入交换机的 port-mac 表容量是否足够呢，这里使用了隧道封装了负载后，就不用担心这个问题了。

2. 此外，就如同虚拟机使用了 vxlan 后一样，有利于打破 ip 地址网段对二层网络规模的限制，打造出一个大二层的网络。

CentOS 6/ 7 系列安装 Docker http://www.linuxidc.com/Linux/2014-07/104768.htm

Docker 的搭建 Gitlab CI 全过程详解 http://www.linuxidc.com/Linux/2013-12/93537.htm

Docker 安装应用 (CentOS 6.5_x64) http://www.linuxidc.com/Linux/2014-07/104595.htm

在 Docker 中使用 MySQL http://www.linuxidc.com/Linux/2014-01/95354.htm

在 Ubuntu Trusty 14.04 (LTS) (64-bit) 安装 Docker http://www.linuxidc.com/Linux/2014-10/108184.htm

Docker 安装应用 (CentOS 6.5_x64) http://www.linuxidc.com/Linux/2014-07/104595.htm

Ubuntu 14.04 安装 Docker http://www.linuxidc.com/linux/2014-08/105656.htm