容器网络聚焦：CNM和CNI

小贴士

容器的网络技术突飞猛进。业界逐渐聚焦到Docker的CNM和CoreOS的CNI。

目前关于Linux容器网络接口的配置有两种的可能的标准：容器网络模型（CNM）和容器网络接口（CNI）。网络是至关复杂的，并且提供某种功能的方式也多种多样。

在斟酌某项技术的时候，咱们须要考虑采纳的成本；是否会增长对供应商的依赖。社区的采纳程度和支持程度也是比较重要的考量。插件开发者还须要考虑哪一种方式相对比较容易实现。

Container Network Model(CNM)

CNM是一个被 Docker 提出的规范。如今已经被Cisco Contiv, Kuryr, Open Virtual Networking (OVN), Project Calico, VMware 和 Weave 这些公司和项目所采纳。

Libnetwork是CNM的原生实现。它为Docker daemon和网络驱动程序之间提供了接口。网络控制器负责将驱动和一个网络进行对接。每一个驱动程序负责管理它所拥有的网络以及为该网络提供的各类服务，例如IPAM等等。由多个驱动支撑的多个网络能够同时并存。网络驱动能够按提供方被划分为原生驱动(libnetwork内置的或Docker支持的)或者远程驱动 (第三方插件)。原生驱动包括 none, bridge, overlay 以及 MACvlan。驱动也能够被按照适用范围被划分为本地（单主机）的和全局的 (多主机）。

『Network Sandbox』- 一个容器内部的网络栈。

『Endpoint』- 一个一般成对出现的网络接口。一端在网络容器内，另外一端在网络内。 一个Endpoints能够加入一个网络。一个容器能够有多个endpoints。

『Network』-一个endpoints的集合。该集合内的全部endpoints能够互联互通。

最后，CNM还支持标签(labels)。Lable是以key-value对定义的元数据。用户能够经过定义label这样的元数据来自定义libnetwork和驱动的行为。

Container Network Interface(CNI)

CNI是由CoreOS提出的一个容器网络规范。已采纳改规范的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。另外 Contiv Networking, Project Calico 和 Weave这些项目也为CNI提供插件。

CNI 的规范比较小巧。它规定了一个容器runtime和网络插件之间的简单的契约。这个契约经过JSON的语法定义了CNI插件所须要提供的输入和输出。

一个容器能够被加入到被不一样插件所驱动的多个网络之中。一个网络有本身对应的插件和惟一的名称。CNI 插件须要提供两个命令：一个用来将网络接口加入到指定网络，另外一个用来将其移除。这两个接口分别在容器被建立和销毁的时候被调用。

CNI Flow

容器runtime首先须要分配一个网络命名空间以及一个容器ID。而后连同一些CNI配置参数传给网络驱动。接着网络驱动会将该容器链接到网络并将分配的IP地址以JSON的格式返回给容器runtime。

Mesos 是最新的加入CNI支持的项目。Cloud Foundry的支持也正在开发中。当前的Mesos网络使用宿主机模式，也就是说容器共享了宿主机的IP地址。Mesos正在尝试为每一个容器提供一个本身的IP地址。这样作的目的是使得IT人员能够自行选择适合本身的组网方式。

目前，CNI的功能涵盖了IPAM, L2 和 L3。端口映射(L4)则由容器runtime本身负责。CNI也没有规定端口映射的规则。这样比较简化的设计对于Mesos来说有些问题。端口映射是其中之一。另一个问题是：当CNI的配置被改变时，容器的行为在规范中是没有定义的。为此，Mesos在CNI agent重启的时候，会使用该容器与CNI关联是的配置。

CNI和CNM

这种模块化驱动的方式可与说对运维人员更有吸引力。由于运维人员能够比较灵活的选择适合现有模式的驱动。两种方案都提供了独立的扩展点，也就是插件的接口。这使得网络驱动能够建立、配置和链接网络。也使得IPAM能够配置，发现和管理IP地址。这种分离让编排变得容易。

CNM 模式下的网络驱动不能访问容器的网络命名空间。这样作的好处是libnetwork能够为冲突解决提供仲裁。一个例子是：两个独立的网络驱动提供一样的静态路由配置，可是却指向不一样的下一跳IP地址。与此不一样，CNI容许驱动访问容器的网络命名空间。CNI正在研究在相似状况下如何提供仲裁。

CNI支持与第三方IPAM的集成，能够用于任何容器runtime。CNM从设计上就仅仅支持Docker。因为CNI简单的设计，许多人认为编写CNI插件会比编写CNM插件来得简单。

这些模型增进了系统的模块化，增长了用户的选择。也促进了第三方网络插件以创新来提供更高级的网络功能。

总结

容器网络领域随着供应商和各类项目的不断变化而变化。有些被合并，例如Docker兼并SocketPlan；Flannel到Tigera的迁移 - Tigera的Canal将Calico和Flannel两个项目组合在一块儿了。 CoreOS会继续为Flannel提供支持，而且会将Canal集成在它们的企业级Kubernetes方案 - Tectonic 里面。同时，新的发布版本也带来新的变化。Docker 1.12中包括的underlay和load-balancing等新特性，也将该项目的网络支持提高到新的高度。

虽然在容器网络方面有各类各样的技术，咱们值得庆幸的是（至少是如今）容器生态圈基本上聚焦在这两个模型上。开发人员和运维人员都但愿可以最终自动化网络配置。在没能彻底自动配置以前，解决方案之一是一些人工参与的预先配置好的资源。好比运维人员能够预先分配一些网络，包括IP地址空间，IPAM，QoS等等。开发人员能够根据本身应用的须要来从中选择网络。

微信搜索：Wise2C ∣ 一个有趣的公众号