宜信云平台专家:使用开源Calico构建Docker多租户网络

PaaS 平台的网络需求

在使用 Docker 构建 PaaS 平台的过程中,我们首先遇到的问题是需要选择一个满足需求的网络模型:

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

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

  • Docker 原生的 Bridge 模型:NAT 机制导致无法使用容器 IP 进行跨服务器通讯(后来发现自定义网桥可以解决通讯问题,但是觉得方案比较复杂)
  • Docker 原生的 Host 模型:大家都使用和服务器相同的 IP,端口冲突问题很麻烦
  • Weave OVS 等基于隧道的模型:由于是基于隧道的技术,在用户态进行封包解包,性能折损比较大,同时出现问题时网络抓包调试会很蛋疼

在对上述模型都不怎么满意的情况下,发现了一个还不怎么被大家关注的新项目:Project Calico

Project Calico 是纯三层的 SDN 实现,它基于 BPG 协议和 Linux 自己的路由转发机制,不依赖特殊硬件,没有使用 NAT 或 Tunnel 等技术。能够方便的部署在物理服务器,虚拟机(如 OpenStack)或者容器环境下。同时它自带的基于 Iptables 的 ACL 管理组件非常灵活,能够满足比较复杂的安全隔离需求。

使用 Calico 来实现 Docker 的跨服务器通讯

环境准备

  • 两个 Linux 环境 node1|2(物理机,VM 均可),假定 IP 为:192.168.78.21|22
  • 为了简单,请将 node1|2 上的 Iptables INPUT 策略设为 ACCEPT,同时安装 Docker
  • 一个可访问的 Etcd 集群(192.168.78.21:2379),Calico 使用其进行数据存放和节点发现

启动 Calico

在 node1|2 上面下载控制脚本:

# wget https://github.com/projectcalico/calico-docker/releases/download/v0.4.9/calicoctl

启动

# export ETCD_AUTHORITY=192.168.78.21:2379
# ./calicoctl node --ip=192.168.78.21|22

docker ps 能看到:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
74cc20b90b0f calico/node:v0.4.9 "/sbin/my_init" 24 seconds ago Up 23 seconds calico-node 

部署测试实例

在 Calico 中,有一个 Profile 的概念(类似 AWS 的 Security Group),位于同一个 Profile 中的实例才能互相通讯,所以我们先创建一个名为 db 的 Profile:

在 node1 上执行:

[node1]# ./calicoctl profile add db

然后启动测试实例:

[node1]# export DOCKER_HOST=localhost:2377
[node1]# docker run -n container1 -e CALICO_IP=auto -e CALICO_PROFILE=db -td ubuntu

这里大家注意,我们注入了两个环境变量:CALICO_IP 和 CALICO_PROFILE 。

前者告诉 CALICO 自动进行 IP 分配,后者将此容器加入到 Profile db 中。

那么 Calico 是怎么做到在容器启动的时候分配 IP 的呢?

大家注意我们在 run 一个容器前,先执行了一个 export,这里其实就是将 Docker API 的入口劫持到了 Calico 那里。Calico 内部是一个 twistd 实现的 Python Daemon,转发所有 Docker 的 API 请求给真正的 Docker 服务,如果发现是 start 则插入自己的逻辑创建容器的网络栈。

容器启动后我们查看 container1 获取的 IP 地址:

[container1]# ip addr
...
8: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 1e:48:3e:ec:71:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/32 scope global eth1
valid_lft forever preferred_lft forever

我们会看到 eth1 这个网络接口被设置了 IP 192.168.0.1

同样在 node2 上面部署 container2。

默认设置下 IP 会在 192.168.0.0/16 中按顺序分配,所以 container2 会是192.168.0.2

然后我们就会发现 container1|2 能够互相 ping 通了!

路由实现

接下来让我们看一下在上面的 demo 中,Calico 是如何让不在一个节点上的两个容器互相通讯的:

  • Calico 节点启动后会查询 Etcd,和其他 Calico 节点使用 BGP 协议建立连接
[node1]# netstat -anpt | grep 179
tcp 0 0 0.0.0.0:179 0.0.0.0:* LISTEN 21887/bird
tcp 0 0 192.168.78.21:46427 192.168.78.22:179 ESTABLISHED 21887/bird
  • 容器启动时,劫持相关 Docker API,进行网络初始化
    • 如果没有指定 IP,则查询 Etcd 自动分配一个可用 IP
    • 创建一对 veth 接口用于容器和主机间通讯,设置好容器内的 IP 后,打开 IP 转发
    • 在主机路由表添加指向此接口的路由
主机上:
[node1]# ip link show
...
7: cali2466cece7bc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 96:c4:86:4d:d7:2c brd ff:ff:ff:ff:ff:ff
容器内:
[container1]# ip addr
...
8: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 1e:48:3e:ec:71:52 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/32 scope global eth1
valid_lft forever preferred_lft forever
主机路由表:
[node1]# ip route
...
192.168.0.1 dev cali2466cece7bc scope link
  • 然后将此路由通过 BGP 协议广播给其他所有节点,在两个节点上的路由表最终是这样的:
[node1]# ip route
...
192.168.0.1 dev cali2466cece7bc scope link
192.168.0.2 via 192.168.78.22 dev enp0s8 proto bird
[node2]# ip route
...
192.168.0.1 via 192.168.78.21 dev enp0s8 proto bird
192.168.0.2 dev caliea3aaf5a7be scope link

大家看这个路由,node2 上面的 container2 要访问 container1(192.168.0.1),通过查路由表得知需要将包转给 192.168.78.21,也就是 node1。形象的展示数据流向是这样的:

container2[eth1] -> node2[caliea3aaf5a7be] -> route -> node1[cali2466cece7bc] -> container1[eth1]

至此,跨节点通讯打通,整个流程没有任何 NAT,Tunnel 封包。所以只要三层可达的环境,就可以应用 Calico。

利用 Profile 实现 ACL

在之前的 demo 中我们提到了 Profile,Calico 每个 Profile 都自带一个规则集,用于对 ACL 进行精细控制,如刚刚的 db 的默认规则集是:

[node1]# ./calicoctl profile db rule json
{
"id": "db",
"inbound_rules": [
{
"action": "allow",
"src_tag": "db"
}
],
"outbound_rules": [
{
"action": "allow"
}
]
}

这个规则集表示入连接只允许来自 Profile 名字是 db 的实例,出连接不限制,最后隐含了一条默认策略是不匹配的全部 drop,所以同时位于不同 Profile 的实例互相是不能通讯的,这就解决了隔离的需求。

下面是一个更复杂的例子:

在常见的网站架构中,一般是前端 WebServer 将请求反向代理给后端的 APP 服务,服务调用后端的 DB:

WEB -> APP -> DB

所以我们要实现:

  • WEB 暴露 80 和 443 端口
  • APP 允许 WEB 访问
  • DB 允许 APP 访问 3306 端口
  • 除此之外,禁止所有跨服务访问

那么我们就可以如此构建 json:

对于 WEB

[node1]# cat web-rule.json
{
"id": "web",
"inbound_rules": [
{
"action": "allow",
"src_tag": "web"
},
{
"action": "allow",
"protocol": "tcp",
"dst_ports": [
80,
443
]
}
],
"outbound_rules": [
{
"action": "allow"
}
]
}
[node1]# ./calicoctl profile web rule update < web-rule.json

入站规则我们增加了一条允许 80 443

对于 APP

[node1]# cat app-rule.json
{
"id": "app",
"inbound_rules": [
{
"action": "allow",
"src_tag": "app"
},
{
"action": "allow",
"src_tag": "web"
}
],
"outbound_rules": [
{
"action": "allow"
}
]
}
[node1]# ./calicoctl profile app rule update < app-rule.json

对于后端服务,我们只允许来自 web 的连接。

对于 DB,我们在只允许 APP 访问的基础上还限制了只能连接 3306。

[node1]# cat db-rule.json
{
"id": "db",
"inbound_rules": [
{
"action": "allow",
"src_tag": "db"
},
{
"action": "allow",
"src_tag": "APP",
"protocol": "tcp",
"dst_ports": [
3306
]
}
],
"outbound_rules": [
{
"action": "allow"
}
]
}
[node1]# ./calicoctl profile db rule update < db-rule.json

很简单的几条规则,我们就实现了上述需求。

Profile 高级特性:Tag

有同学可能说,在现实环境中,会有多组不同的 APP 都需要访问 DB,如果每个 APP 都在 db 中增加一条规则也很麻烦同时还容易出错。

这里我们可以利用Profile 的高级特性 Tag 来简化操作:

  • 每个 Profile 默认拥有一个和 Profile 名字相同的 Tag
  • 每个 Profile 可以有多个 Tag,以 List 形式保存

利用 Tag 我们可以将一条规则适配到指定的一组 Profile 上。

参照上面的例子,我们给所有需要访问 DB 的 APP 的 Profile 都加上 db-users这个 Tag:

[node1]# ./calicoctl profile app1 tag add db-users
[node1]# ./calicoctl profile app2 tag add db-users
[node1]# ./calicoctl profile app3 tag add db-users
...

然后修改 db-rule.json 为:

{
"id": "db",
"inbound_rules": [
{
"action": "allow",
"src_tag": "db"
},
{
"action": "allow",
"src_tag": "db-users",
"protocol": "tcp",
"dst_ports": [
3306
]
}
],
"outbound_rules": [
{
"action": "allow"
}
]
}

将之前的 src_tag: app 替换为 src_tag: db-users。这样所有打了 db-user 这个 Tag 的实例就都能访问数据库了。

Profile 的实现

Profile 的实现基于 Iptables 和 IPSet。我们以刚刚的 db 规则集中 inbound 部分为例:

Calico 在启动后会在 Iptables 中新建一些 Chain,数据包会在不同的 Chain 之间跳转,下面我截取了一些关键的规则列表:

[node1]# iptables -n -L -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
target prot in out source destination
felix-FORWARD all * * 0.0.0.0/0 0.0.0.0/0
Chain felix-FORWARD (1 references)
target prot in out source destination
felix-TO-ENDPOINT all * cali+ 0.0.0.0/0 0.0.0.0/0
Chain felix-TO-ENDPOINT (1 references)
target prot in out source destination
felix-to-2466cece7bc all * cali2466cece7bc 0.0.0.0/0 0.0.0.0/0 [goto]
Chain felix-to-2466cece7bc (1 references)
target prot in out source destination
felix-p-db-i all * * 0.0.0.0/0 0.0.0.0/0
Chain felix-p-db-i (2 references)
target prot in out source destination
RETURN all * * 0.0.0.0/0 0.0.0.0/0 match-set felix-v4-db src
RETURN tcp * * 0.0.0.0/0 0.0.0.0/0 match-set felix-v4-db-users src multiport dports 3306

这个略复杂,我们慢慢看。基本上数据包是从上到下一步步跳转的。

当发给 container1 的数据包到达 node1 后,由于目标 IP 192.168.0.1node1 自身 IP 不同,会被放入 FORWARD 链,然后跳转到felix-FORWARD,通过查询路由表:

192.168.0.1 dev cali2466cece7bc scope link

得知下一跳接口为 cali2466cece7bc,于是先跳转到felix-TO-ENDPOINT,再跳转到 felix-to-2466cece7bc

在这里,定义了具体的 ACL 列表,felix-p-db-i,这个 db 是不是很眼熟?

对,就是这个 container 所属 Profile 的名字,而 felix-p-db-i 中就是 Profiledb 的 inbound 规则集。而 felix-p-db-i 的内容:

match-set felix-v4-db src
match-set felix-v4-db-users src multiport dports 3306

felix-v4-dbfelix-v4-db-users 是不是也很熟悉?

db 规则集中的两个 Tag 在这里加了个前缀变成了 IPSet,它包括了所有打了这个 Tag 的 IP 列表:

[node1]# ipset list
...
Name: felix-v4-db
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16576
References: 1
Members:
192.168.0.1
192.168.0.2

至此,ACL 部分分析完毕。可见 Calico 灵活运用了 Iptables 的种种高级特性。

性能测试

来自官方测试结果

测试环境

  • 8 core CPU
  • 64GiB RAM
  • 10Gb 网卡直连
  • Ubuntu 14.04.2 with 3.13 Kernel(3.10 版本的 Kernel 修复了一些 veth 性能的问题)
  • 没有额外的内核参数调优

测试了四种场景:

  • 物理服务器(基准)
  • 部署了 Calico 的容器之间
  • 部署了 Calico 的 OpenStack VM 之间
  • 部署了 OVS with VxLAN 的 OpenStack VM 之间

测试了两种数据大小:

  • 20000 byte
  • 500 byte

吞吐量 & CPU 使用率测试

吞吐量极限

同一时刻 CPU 的使用率

把它们合并成一张图就是每 Gb/s 的 CPU 使用率

可以看到,部署了 Calico 的两个场景都非常贴近物理服务器的性能。

延迟测试

测试方法是:节点间交换 1 byte 数据包

这个结果显示,Calico 容器非常接近物理服务器,而 OpenStack 场景由于网络虚拟化的缘故延迟稍大。

结论

测试结果表明,Calico 的性能非常接近物理服务器,比基于隧道的 OVS 性能好很多。

Calico 的发展

Calico 和 Docker 一样是很年轻的项目,但是坑比后者少多了,我遇到了一些,如docker inspect 没有显示 Calico 分配的 IP,BGP 客户端重启姿势不正确导致路由周期性消失重建等等。但是他们的开发进度非常快,一个 issue 提出来到修复可能就一两天时间(再次鄙视 Docker)。

目前唯一一个比较麻烦的问题是,Calico 这种劫持 Docker API 的方式,容器的网络栈是在容器启动后才进行初始化,所以在头几秒其实是没有网络可用的,这会导致那些启动就要访问网络的容器挂掉。解决方案有两个:

  • 升级 Docker 到支持 libnetwork 的版本,Calico 在新版本(>0.5)中支持了 libnetwork,理论上能够解决这个问题。但是代价要踩新版本 Docker 带来的更多的坑。
  • 自定义容器的 CMD,实现一个 entry 脚本,待网络可用后再 exec 载入真正的进程。

Q&A

Q:自定义容器的 CMD,实现一个 entry 脚本,待网络可用后再 exec 载入真正的进程。 有没有具体的?

主要实现方式就是 Dockerfile 中的 CMD 可以这个样子: /entry.sh your-cmd 。这个 entry.sh 中判断 IP 是否已经分配好,如果没有就 sleep 重试。分配好后再用 exec 载入后面的 your-cmd 。

Q:是否每增加一个容器宿主机就需要增加一条路由?如果容器数量很多会有问题吗?

是的。关于这个问题我咨询过开发团队,他们表示压测过单机 10 万条路由,没有问题。同时将来会推出路由段的广播机制,即:每台服务器使用一小段,之间只需要广播此段即可。

Q:如果要做容器间通讯限速,Calico能做吗?

由于每个由 Calico 管理的容器在宿主机上面都有一个唯一的网络接口(veth 的一端),通过限制此接口流量即可进行限速。Calico 官方没有提供这个功能,我们可以用常规的其他手段解决。同时这个接口还有一个好处就是非常容易做容器的流量监控,只要看接口计数器即可。

Q:Calico 和 Kubernetes 的整合你们尝试过吗?Calico只是接管了容器间的通信,和 Kubernetes 的 Service Cluster IP 没有关系吧?

我们没有使用 Kubernetes 的解决方案,而是自行开发的调度编排等组件。Cailco 官方是支持的并且有相关文档可以参考。具体请参考:https://github.com/projectcalico/calico-docker/blob/master/docs/kubernetes/README.md

高永超(flex) 宜信大数据创新中心云平台运维专家,目前专注于 DevOps 和 PaaS 平台开发(基础设施方向),曾在豆瓣担任过 SA Team Leader,《Pro Puppet》第一版中文译者。

未经允许不得转载:氢网 » 宜信云平台专家:使用开源Calico构建Docker多租户网络

支付宝扫码打赏 微信打赏

欢迎点击上方按钮对我打赏

分享到:更多 ()

评论 3

评论前必须登录!

 

  1. #3

    export DOCKER_HOST=localhost:2377(我的etcd client端口是2380,这里我也对应的改了)
    请问这个是etcd的端口吗? 我在这样操作了以后run容器报错如下:
    docker: Error response from daemon: 404 page not found.

    cc9个月前 (2016-04-21)
  2. #2

    忽略上面的问题,
    按照您的方式,最后calico并没有给容器自动分配一个IP,容器的Ip是默认的172.17.0.3(这个不是我在pool中定义的)
    +————-+——————-+
    | IPv4 CIDR | Options |
    +————-+——————-+
    | 10.1.0.0/16 | ipip,nat-outgoing |
    +————-+——————-+
    手动使用calicoctl命令可以给容器加IP,请问这是为啥啊?

    cc9个月前 (2016-04-21)
  3. #1

    本机上是不是应该劫持Unix端口?

    cc9个月前 (2016-04-21)