CNM 基于 libnetwork，是 Docker 内置的模型规范，它的总体架构如下图所示：

可以看到，CNM 规范主要定义了以下三个组件：

  • Sandbox: 每个 Sandbox 包含一个容器网络栈 (network stack)的配置：容器的网口、路由表和 DNS 设置等，Sandbox 可以通过 Linux 网络命名空间 netns 来实现
  • Endpoint: 每个 Sandbox 通过 Endpoint 加入到一个 Network 里，Endpoint 可以通过 Linux 虚拟网络设备 veth 对或者 OvS internal port 来实现
  • Network: 一组能相互直接通信的 Endpoint，Network 可以通过 Linux 网桥设备 bridge，VLAN 等实现

可以看到，底层实现原理还是我们之前介绍过的 Linux 虚拟网络设备，网络命名空间等。CNM 规范的典型场景是这样的：用户可以创建一个或多个 Network，一个容器 Sandbox 可以通过 Endpoint 加入到一个或多个 Network，同一个 Network 中容器 Sanbox 可以通信，不同 Network 中的容器 Sandbox 隔离。这样就可以实现从容器与网络的解耦，也就是锁，在创建容器之前，可以先创建网络，然后决定让容器加入哪个网络。

Why Kubernetes doesn’t use libnetwork

但是，为什么 Kubernetes 没有采用 CNM 规范标准，而是选择 CNI，感兴趣的话可以去看看 Kubernetes 的官方博客文章 Why Kubernetes doesn’t use libnetwork，总的来说，不使用 CNM 最关键的一点是，是因为 Kubernetes 考虑到 CNM 在一定程度上和 container runtime 耦合度太高，因此以 Kubernetes 为领导的其他一些组织开始制定新的 CNI 规范。CNI 并不是 Docker 原生支持的，它是为容器技术设计的通用型网络接口，因此 CNI 接口可以很容易地从高层向底层调用，但从底层到高层却不是很方便，所以一些常见的 CNI 插件很难在 Docker 层面激活。但是这两个模型全都支持插件化，也就是说我们每个人都可以按照这两套网络规范来编写自己的具体网络实现。

Reference