Docker container communication scheme comparison

This series of articles will introduce the relevant knowledge of Docker:

In the early days, Docker only had a network solution on a single machine. In version 1.19, a native overlay network solution was introduced, but its performance loss is large and may not be able to meet the requirements of some production environments. In addition to the solutions provided by Docker, there are other open source solutions. This article will first introduce various existing solutions, and then summarize the selection and consideration of container networks by some enterprises in the production environment based on the publicly shared information.

1. Existing cross-host container networking solutions

1.1 Flannel Container Network

Flannel is a CoreOS-led solution. Flannel assigns an IP segment to the Docker daemon of each host, and maintains a cross-host routing table through etcd. IPs between containers can be connected to each other. When two cross-host containers want to communicate, they will be modified on the host. The header of the data packet, modify the destination address and source address, send it to the target host through the routing table, and then unpack it. The way of encapsulation can support udp, vxlan, host-gw, etc., but if a container wants to expose services, it still needs to map IP to the host side.

1.2 Calico Network Solution

Calico is a young project, based on the BGP protocol and implemented entirely through Layer 3 routing. Calico can be used in virtual machines, physical machines, and container environments. On the host where Calico runs, you can see a large number of routing tables composed of linux routes, which are dynamically generated and managed by calico through its own components. This implementation does not use tunnels and NAT, resulting in no performance loss, and the performance is very good. From a technical point of view, it is a very superior solution. The advantage of this is that the IP of the container can be accessed directly to the outside world, and can be directly assigned to the business IP, and if the network device supports BGP, it can be used to implement a large-scale container network. But the advantages brought by BGP also bring its disadvantages. The BGP protocol is rarely accepted within the enterprise, and the enterprise network administrator is reluctant to enable the BGP protocol on the routers across the network.

1.3 Summary

Cross-host container networking solutions fall into three categories:

Tunnel scheme: such as Flannel's VxLan. The feature is that there are no high requirements for the underlying network. Generally speaking, as long as it is reachable at Layer 3, a tunnel-based container network can be constructed as long as it is in a Layer 3 reachable network. The problem is also obvious. A consensus is that the complexity will increase with the growth of the node size, and it is more troublesome to track network problems. This is a point that needs to be considered in the case of large-scale clusters.
Routing solution: Routing technology realizes cross-host container intercommunication from three layers, no NAT, high efficiency, and can be integrated with the current network, each container can be assigned a service IP like a virtual machine. However, the routing network also has problems. The routing network has a relatively large impact on the existing network equipment. The routing table of the router should have a space limit of 20,000 to 30,000 entries. Most of the application scenarios of containers are to run microservices, and the number of sets is large. If tens of thousands of new container IPs are impacted into the routing table, the physical devices at the lower layer cannot bear it; and each container is assigned a service IP, and the service IP consumption will be very fast.
VLAN: All containers and physical machines are in the same VLAN.

1.4 A netizen's performance test report

Source: https://www.douban.com/note/530365327/

in conclusion:

plan	in conclusion	Advantage	disadvantage
weave(udp)	It's really miserable, don't think about the production environment. Looking at their architecture, I feel that even fast-data-path doesn't make much sense.	without	就是个渣渣，概念好毛用都没
calico	calico 的 2 个方案都有不错的表现，其中 ipip 的方案在 big msg size 上表现更好，但蹊跷是在 128 字节的时候表现异常，多次测试如此。bgp 方案比较稳定，CPU 消耗并没有 ipip 的大，当然带宽表现也稍微差点。不过整体上来说，无论是 bgp 还是 ipip tunnel，calico 这套 overlay sdn 的解决方案成熟度和可用度都相当不错，为云上第一选择。	性能衰减少，可控性高，隔离性棒	操作起来还是比较复杂，比如对 iptables 的依赖什么的
flannel	flannel 的 2 个方案表现也凑合，其中 vxlan 方案是因为没法开 udp offload 导致性能偏低，其他的测试报告来看，一旦让网卡自行解 udp 包拿到 mac 地址什么的，性能基本上可以达到无损，同时 cpu 占用率相当漂亮。udp 方案受限于 user space 的解包，仅仅比 weave(udp) 要好一点点。好的这一点就是在实现方面更加高效。	部署简单，性能还行，可以兼容老版本 docker 的启动分配行为，避免 launcher	没法实现固定 IP 的容器漂移，没法多子网隔离，对上层设计依赖度高，没有 IPAM，对 docker 启动方法有绑定
docker 原生 overlay 方案	其实也是基于 vxlan 实现的。受限于 cloud 上不一定会开的网卡 udp offload，vxlan 方案的性能上限就是裸机的 55% 左右了。大体表现上与 flannel vxlan 方案几乎一致。	docker 原生，性能凑合	对内核要求高（>3.16），对 docker daemon 有依赖需求 ( consul / etcd )，本身驱动实现还是略差点，可以看到对 cpu 利用率和带宽比同样基于 vxlan 的 flannel 要差一些，虽然有 api 但对 network 以及多子网隔离局部交叉这种需求还是比较麻烦，IPAM 就是个渣

综上，云上能用 BGP 就果断上 calico bgp 方案，不能用 BGP 也可以考虑 calico ipip tunnel 方案，如果是 coreos 系又能开 udp offload，flannel 是不错的选择。Docker overlay network 还有很长一段路要走，weave 就不用考虑了。

2. 若干企业生产环境中的容器网络方案

2.1 PPTV Docker网络解决方案 - 基于 linux bridge

（0）PPTV 容器云架构

（1）网络需求

网络组人力不足以维护一个Overlay网络，Overlay网络出问题排查复杂，会出现失控的状态。
隧道技术影响性能，不能满足生产环境对网络性能的要求。
开启bgp对现有网络改动太大，无法接受。
运维组同学希望能通过网络桥接的方案解决容器网络。

（2）选中的方案

最终 PPTV 选中基于docker的bridge模式，将默认的docker bridge网桥替换为 linuxbridge，把 linuxbridge 网段的 ip 加入到容器里，实现容器与传统环境应用的互通。

首先会在该主机上添加一个linux bridge，把主机网卡，可以是物理机的，也可以是虚拟机的，把这个网卡加入bridge里面，bridge配上网卡原本的管理IP。
创建一个新的docker bridge网络，指定bridge子网，并将该网络的网桥绑定到上一步创建的网桥上。

docker network create --gateway10.199.45.200 --subnet 10.199.45.0/24 -o com.docker.network.bridge.name=br-oak--aux-address "DefaultGatewayIPv4=10.199.45.1" oak-net

容器启动时候，指定容器网络为第二步中创建的bridge网络，同时为容器指定一个该网络子网内的IP。容器启动后网络IP默认即可与外界互通。

（3）问题及解决方案

通过网桥的方式解决容器网络有两个问题:

容器跨主机漂移要求宿主机在同一个VLAN 中：linux bridge 只能添加跟 slavehost 同一个vlan的IP，也就是说容器IP必须要和宿主机在同一vlan下，这在一定程度上就限制了容器跨宿主机漂移的范围。不过这个问题在PPTV 的生产环境中天然不存在，因为我们的生产环境中，每个数据中心的主机都在一个很大的子网内，基本能满足容器在整个数据中心的任意节点下漂移。
跨主机的 IP 地址分配需要避免地址冲突：要让容器 IP 在不同的宿主机上漂移，宿主机的 docker 网络需要使用同一个CIDR，也就是各宿主机的容器使用同一个网段。而不同宿主机的使用同一个容器网段就会涉及到IPAM的问题，因为宿主机的docker daemon只知道他本机上的容器使用了哪些IP，而这些IP在其他宿主机上有没有被使用，是不知道的。在默认的docker bridge中，因为这些ip不会直接与外部通信，所以容器使用相同IP也不会有问题，但是当容器网络通过linux bridge打通以后，所有容器都是2层互通的，也就是会出现IP冲突的问题。为了解决上边提到的问题，实现全局的IP管控，我们开发了IP池管理平台，实现对容器IP的分配管理。
需要更新服务自动注册、自动发现：因为原先的方案是基于NAT的模式做的，而现在实现了独立IP的功能。我们需要将现有的平台与PPTV内部的DNS做自动化对接，每当有容器创建和生成时，都会自动对容器的IP做DNS解析。
负载均衡：PPTV的负载均衡基本都是通过LVS + nginx实现的，但对于后台的容器应用来说，每次扩容和缩容、或者创建新的应用，负载均衡的后端配置也是需要自动更新的。

2.2 宜信的容器网络解决方案 - 基于 Calico

（1）网络需求

让每个容器拥有自己的网络栈，特别是独立的 IP 地址
能够进行跨服务器的容器间通讯，同时不依赖特定的网络设备
有访问控制机制，不同应用之间互相隔离，有调用关系的能够通讯

（2）调研过程和最终的选择

调研了几个主流的网络模型：

Docker 原生的 Bridge 模型：NAT 机制导致无法使用容器 IP 进行跨服务器通讯（后来发现自定义网桥可以解决通讯问题，但是觉得方案比较复杂）
Docker 原生的 Host 模型：大家都使用和服务器相同的 IP，端口冲突问题很麻烦
Weave OVS 等基于隧道的模型：由于是基于隧道的技术，在用户态进行封包解包，性能折损比较大，同时出现问题时网络抓包调试会很蛋疼
Project Calico 是纯三层的 SDN 实现，它基于 BPG 协议和 Linux 自己的路由转发机制，不依赖特殊硬件，没有使用 NAT 或 Tunnel 等技术。能够方便的部署在物理服务器，虚拟机（如 OpenStack）或者容器环境下。同时它自带的基于 Iptables 的 ACL 管理组件非常灵活，能够满足比较复杂的安全隔离需求。

各种方案的限制：

Docker Bridge：每个容器里面都有一个虚拟网卡，和主机上的虚拟网卡做配合，所有容器内的虚拟网卡都可以和主机通信。通过端口映射，我调用对方的容器服务的时候，不能使用该容器直接的地址，必须使用它主机的地址。因为有了这样一个转发，网络通讯的性能有所损耗。当然，还有一个问题更严重，访问你的容器先要搞清楚你的主机是什么，这样网络通讯会跳来跳去。不但麻烦，还会带来端口冲突。每创建一个容器会绑定一个端口，怎么管理好这些端口是一个很大的挑战。
Fannel：这个方法有几个问题，第一个是要做封包的操作，这会带来网络性能损失。第二个问题是每个主机上的容器是固定的，容器的不同主机之前的迁移必然带来IP的变化。
Weave：它的思路是共享IP而非绑定。在传输层先找到目标地址，然后把包发到对端，节点之间互相通过协议共享信息。Flannel和Weave的特点是类似的，都用的是UDP或者是VxLAN的技术。事实上使用UDP性能是很差的，VxLAN和UDP差不多，它有一个网络切隔，而且在里面可以跑二层协议。还有一种是IPIP封包，直接把一个IP包封装在一个IP包里面。以上不难看出，原生网络性能比较差，使用UDP的时候性能损失在50%以上，使用VxLAN也会有20%～30%的损耗。所以我要在内核上封包，使用硬件来解决这些问题。而且容器和容器之间出现通讯故障，调试的时候非常困难

（3）Calico 使用总结

Calico 的应用场景主要是IDC内部，推荐部署在二层网络上，这样所有路由器之间是互通的。这种场景是大二层的解决方案，所有服务器都在里面。但大二层主要的问题是弹性伸缩的问题。频繁开关机的时候，容器启停虽然不影响交换机，但容易产生广播风暴。网络规模太大的时候，一旦出现了这样的问题，整个网络都会有故障，这个问题还没有解决的特别好。
Calico作为一个纯二层的应用问题不大。我们可以把集群分成了很多网段，对外是三层网络的结构。集群内部分成多个自制域，比如一个机柜是一个自制域，之间通过交换路由的方式实现在三层容器到容器的互通。瓶颈在于容器的路由信息容量。所以说本质上它不是一个应对互联网规模的解决方案，但对宜信场景是够用的。
我们实施的时候遇到一些坑，比如容器在启动时没有网络、操作ETCD的时候BGP配置频繁加载，等等，最后我们多一一解决了。我们也发现了driver方案功能方面的弱点，现在还继续使用劫持API的方法。如果要在云上使用，如果支持BGP，直接可以用；如果不支持BGP可以用IPIP。现在英特尔的网卡支持两个协议，一个是GRE、一个是VxLAN。如果真的把它放在云上，我们可以考虑一下把VxLAN引进来，性能上的差别不是很大。