阿里开源富容器引擎 PouchContainer 的 network 链接机制

引言

PouchContainer 是阿里巴巴集团开源的高效、轻量级企业级富容器引擎技术，拥有隔离性强、可移植性高、资源占用少等特性。能够帮助企业快速实现存量业务容器化，同时提升超大规模下数据中心的物理资源利用率。

PouchContainer 源自阿里巴巴内部场景，诞生初期，在如何为互联网应用保驾护航方面，倾尽了阿里巴巴工程师们的设计心血。PouchContainer 的强隔离、富容器等技术特性是最好的证实。在阿里巴巴的体量规模下，PouchContainer 对业务的支撑获得双 11 前所未有的检验，开源以后，阿里容器成为一项普惠技术，定位于「助力企业快速实现存量业务容器化」。

本文将给你们介绍 PouchContainer 实现 network 的机制以及将容器链接到 network 上的原理。为了充分阐述 network 的链接机制，本文将以Connect方法为例，叙述如何动态地将一个 container 链接到一个已存在的 network 上。

一、 PouchContainer 实现 network 的机制

在目前的容器网络虚拟化技术中，Docker 推行的 CNM (Container Network Model）模型是一种通用的解决方案，CNM 构建了一种成熟的容器虚拟化网络模型，并定义了多种供开发者调用的标准化接口。PouchContainer 沿用了 CNM 模型，基于 libnetwork 来实现容器间通讯。下面先对 Sandbox、Endpoint 和 Network 这三个 CNM 中的核心组件进行介绍。

Sandbox

Sandbox 一词在不一样的机制里，被分别赋予了不一样的定义。例如，在 CRI（container runtime interface）里面 sandbox 就表明着pod的概念。而在 CNM 模型里，Sandbox 表明着一个容器的网络栈配置，包含管理容器的网卡，路由表以及 DNS 设置。Sandbox 的具体实现能够经过 linux 系统的 network namespace，一个 FreeBSD Jail 或者其余相似的概念。一个 Sandbox 能够包含多个 Endpoints。

Endpoint

一个 Endpoint 将 Sandbox 链接到 Network 上。一个 Endpoint 的实现能够经过 veth pair，Open vSwitch internal port 或者其余的方式。比较常见的方法是用 veth pair，顾名思义，veth pair必定是成对出现的，所以会存在 veth0 和 veth1 两块网卡。建立容器时，其中一块会被设置到容器内部，充当容器内部的eth0，全部目的地址为容器 IP 的数据包都要通过 eth0 网卡；另外一块（如下称为 veth 设备）则会被链接到宿主机的网桥上。从 veth 设备出去的数据包，会转发到对应的 eth0 设备上，当数据包的目的地址为 eth0 设备的 IP 时，就能被内核协议栈处理。用 veth pair 来链接两个 network namespace，从而创建网络连通关系。一个 Endpoint 只能属于一个 Network，也只能属于一个 Sandbox。

Network

一个 Network 是一组能够相互通讯的 Endpoints 的集合。一个 Network 的实现能够经过 Linux bridge，vlan 或者其余方式。值得一提的是，一个 Network 中能够包含不少个 Endpoints。

能够看到，在以下图所示的结构下，Container A 和Container B 同属于 Backend Network，这两个 Container经过各自紫色的 Endpoint 构成 Network 链接；Container B和 Container C 同属于 Frontend Network，经过蓝色的 Endpoint 构成 Network 链接。所以Container A和Container B之间能够通讯，Container B和Container C之间也能够通讯。

接下来重点看一下 Container B 内部的两个 Endpoints，虽然 Backend Network 和 Frontend Network 在Container B 内都有各自对应的 Endpoint，但紫色 Endpoint 和蓝色 Endpoint 间不构成通讯。所以 Backend Network 和 Frontend Network 是两个彻底隔离的 Network，并不由于链接同一个 Container 而产生连通。显而易见，Container A 和 Container C 间实际上是没法通讯的。

二、PouchContainer 内置的 network 模式

2.1 bridge 模式

bridge 模式是 PouchContainer 默认的网络模式，在建立容器不指定 network 模式，即不写--net参数，该容器就会以 bridge 模式建立。pouchd启动的时候，会自动在主机上建立一个虚拟网桥 p0。后续以 bridge 模式建立容器时，pouchd从 p0 网桥所在的 IP 网段中选取一个未使用的 IP 分配给容器的 eth0 网卡，p0 的 IP 是这些容器的默认网关。

2.2 host 模式

在启动容器的时候，选择 host 模式，那么容器将不会得到独立的 network namespace，而是和主机共享 network namespace。所以，这个容器也就没有本身的网卡和 IP 配置，会使用主机的 IP 和端口，但 fs 和 pid 等与主机仍是隔离的。

2.3 container 模式

以 container 模式建立的容器，会和已经存在的容器共享一个 network namespace，直接沿用其 veth 设备对。

2.4 none 模式

使用 none 模式建立的容器，拥有独立的 network namespace，可是不会对容器进行任何的网络配置。所以，能够认为 none 模式下的容器，是不和其它容器通讯的。不过，在容器建立后，能够再给它添加网卡、配置 IP，这样就能够与同一个 network 下的容器通讯了。

2.5 CNM 与 network 模式的概念交叉

一个 Network 是一个惟一的、可识别的 Endpoint 组，组内的 Endpoint 能够相互通信。对比 CNM 来看，Endpoint 能够简单理解成 veth 设备对，容器的 Sandbox 里能够有多个 Endpoints，每一个 Endpoint 表明和一个特定 Network 的链接关系。

三、network connect 的流程分析

// daemon/mgr/container.go

能够看到在Connect函数里，首先根据传入的参数获取到具体的 container 和 network。而epConfig参数里面，存放的是在 CLI 端经过 flag 传入的参数，如 container 在特定 network 中的别名、指定的 IP 范围等。

查看c.State.Status来判断 container 此时的状态，dead 状态的 container 是没法执行 connect 操做的。对于非 running 可是还 live的container，只是简单地调用updateNetworkConfig（）来更新 container 的网络配置，将传入的epConfig加入到容器的 network 配置中。在这种状况下，不会为 container 分配网卡，所以 container 并无成功连通到 network 中。对于 running 状态的 container，调用connectToNetwork（）来进行后续的操做，connectToNetwork（）会根据给定的 network 和 container 进行网卡的配置，再在主机上分配一个网卡，最后将网卡加入到 container 的 sandbox 里面。这样，container 就成功地链接到 network 上了！具体的流程会在后续进行解析。

c.Write(mgr.Store)的做用，是将 container 链接到 network 上的一系列配置写入 container 的 metadata 里面，这样就保证了数据的持久化。不然，创建的 network 链接只是一次性的，全部的数据和相关配置在pouchd重启后都会丢失。

// daemon/mgr/container.go

endpoint 里面包含三部分的信息，一部分的信息来自于 container，一部分的信息来自 network，最后一部分信息是 connect 命令里 flag 中的配置。buildContainerEndpoint（）的逻辑比较简单，就是获取到 endpoint 须要的 container 相关信息。随后调用了NetworkMgr的EndpointCreate（）来进行具体的构建。

// daemon/mgr/network.go

建立 endpoint 的整个过程，都是调用 libnetwork 来实现的。首先调用endpointOptions（）来构建接口要求的EndpointOption参数，这个 setter 函数类型的参数能将不一样的 option 传递给 network 和 endpoint 的接口。随后调用 libnetwork 的

CreateEndpoint（）接口来进行具体的构建。CreateEndpoint（）执行的实际工做包括为这个 Endpoint 分配 IP 和接口（Iface），对应的配置会被应用到 Endpoint 中，其中包括 iptables 的配置规则和端口信息等。

sandbox 所表明的就是 container 独有的 network namespace，其建立也是基于 libnetwork。sandbox 里面包含 container 创建网络通讯的标志性信息，如 IP 地址、Mac 地址、路由和 DNS 等配置。会对已存在的 sandbox 进行遍历，判断是否存在相应的 sandbox，存在的话就直接返回对应的 sandbox。在 none 模式下，container 沿用主机的 namespace，返回的 sandbox 为空，这时候会建立一个新的 sandbox。sandbox 的建立过程，就是调用 namespace 和 cgroup 来建立一个独立 sandbox 空间。

将 endpoint 加入到 sandbox 的操做，实际上就是将网卡分配给 container 的过程，将 endpoint 分配到的网络资源注入到 sandbox 中。网卡是创建链接的核心，container 经过虚拟网卡链接到 network，从而与其它 container 进行通讯。

最后一步，将变化同步更新到 endpoint 的配置里面。

四、总结

回顾创建 network 链接的整个流程，能够简单的分红几步。container 在通讯时须要惟一的 network namespace 来标志本身，那么就要有 sandbox 的建立；通讯的实现须要网卡做为基础，那么就要有 endpoint 的建立；最后将endpoint 加入 sandbox，创建容器间通讯的基础，链接的创建就成功完成了。

本文做者：酥蕊

阅读原文

本文为云栖社区原创内容，未经容许不得转载。