容器技术系列分享（五）

容器网络

目录

• CNM
• CNI
• CNM vs CNI
• 第三方驱动对比

目前关于容器网络接口的配置有两种标准：容器网络模型（CNM）和容器网络接口（CNI）。

Container Network Model(CNM)

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

Libnetwork 是 CNM 的原生实现，它为 Docker Daemon 的网络驱动程序之间提供了接口。网络控制器负责将驱动和一个网络进行对接。每个驱动程序负责管理它所拥有的网络以及为该网络提供各种服务，例如 IPAM 等。由多个驱动支撑的多个网络可以同时并存。网络驱动可以按提供方被划分为原生驱动（libnetwork 内置的或 Docker 支持的）或者远程驱动（第三方插件）。原生驱动包括 none、bridge、overlay 以及 macvlan。

• Network Sandbox：一个容器内部的网络栈
• Endpoint：一个通常成对出现的网络接口。一端在容器网络内，另一端在网格内。一个 Endpoint 可以加入一个网络。一个容器可以有多个 Endpoint。
• Network：一个 Endpoint 的集合，该集合内的所有 Endpoint 可以互联互通。

最后，CNM 还支持标签（labels），label 是以 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 插件负责为容器配置网络，包括两个基本接口：

配置网络

AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error)

清理网络

DelNetwork(net NetworkConfig, rt RuntimeConf) error

CNM vs CNI

CNM 和 CNI 两种方案都使用了驱动模型或者插件模型来为容器创建网络栈，这样的设计使得用户可以自由选择，两者都支持多个网络驱动被同事使用，也允许容器加入一个或多个网络，两者也都允许容器 runtime 在它自己的命名空间中启动网络。

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

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

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

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

第三方驱动对比

除了上图 5 种网络驱动，其实还有很多，Kubernetes 官方介绍了大概 23 种网络插件。接下来详细对比其中性能较好的几种。

方案	Calico	Contiv	macvlan
优点	纯三层的数据中心解决方案（不依赖overlay），对 OpenStack、Kubernetes、AWS、GCE都比较友好。该方案集成简单。	能够和非容器环境兼容协作，不依赖物理网络具体细节，支持 Policy、ACI、QoS租户，支持物理网卡 sriov 和 offload。该方案配置比较复杂。	Docker 原生，性能衰减少，可控性高，隔离性好。
缺点	操作管理比较复杂，需要定制开发。	集成配置较复杂，相关资料少，学习成本较高，需要定制开发。	集群规模很大时，存在 ARP 广播风暴和交换机 MAC 表超限风险，另外需要自研 QoS 功能。
结论	Calico 基于 BGP 协议的 Overlay SDN 解决方案，企业生产环境如果可以开启 BGP 协议，可以考虑 Calico BGP 方案。	功能强型好，对 CNI 和 CNM 模型支持性好，集群配置较复杂，学习研究成本较高，可以考虑此方案。	初期较少的开发量即可上线（之后需要自研 QoS），通过合理的设计容量规划来规避相关风险时，可以考虑此方案。