译文容器网络模型：CNI+vs+CNM

Posted 2021-04-07 404沙盒

docker 的出现是革命性的，改变了我们开发以及部署项目的方式。社区一直致力于让容器技术标准化，这篇文章主要讨论的是其中的一个方面：网络。

网络层面：虚拟机 vs 容器技术

在开始探讨不同的容器网络标准模型之前，先来从网络角度对比一下虚拟机和 docker。

虚拟机是一整套操作系统层级的虚拟化，它还会虚拟出虚拟网卡（virtual network interface cards (NIC)），这些虚拟网卡会和真正的物理机网卡相连接。

docker 实质上就是一个进程，被 container runtime 统一管理，还会共享一个 Linux kernel。所以，容器有更灵活的网络解决方案：

• 和宿主机是共享同一个network interface和 network namespace

• 连接另外的虚拟网络，使用这个虚拟网络的network interface和 network namespace

容器网络设计

早期的容器网络设计把重点放在了如何连接一个宿主机上的容器，让他们可以和外界进行交互。

在"host"模式中，运行在一个宿主机上的容器使用 host 的network namespace，和宿主机一个ip。为了暴露容器，容器会占用宿主机上的一个端口，通过这个端口和外界通信。所以，你需要手动维护端口的分配，不要使不同的容器服务运行在一个端口上。

上述的两种模式都没有解决一个问题：多 host 网络解决方案。

CNI 和 CNM 的对比

• CNM： Docker 公司（docker container runtime 背后的公司）提出。

• CNI：CoreOS公司提出。

Kubernetes 在处理网络上，没有选择自己再独立创造一个，而是选择了其中的 CNI作为了自己的网络插件。（至于为什么不选择 CNM，可以看看这篇官方的解释：Why Kubernetes doesn’t use libnetwork）。不使用 CNM 最关键的一点，是 k8s 考虑到CNM 在一定程度上和 container runtime 联系相对比较紧密，不好解耦。 有了 k8s 这种巨无霸的选择之后，后来的很多项目都在 CNM 和 CNI 之间选择了 CNI。

下面是两种网络模型的详细对比：

1. CNM

2. CNI

CNI 对外暴露了从一个网络里面添加和剔除容器的接口。CNI 使用一个 json 配置文件保存网络配置信息。和 CNM 不一样，CNI 不需要一个额外的分布式存储引擎。

总结

CNI目前已经获得了众多开源项目的青睐，比如 K8S、Memos、Cloud Foundry。同时被Cloud Native Computing Foundation所认可。CNCF 背后有众多的科技大亨，所以可以预见，CNI 将会成为未来容器网络的标准。

原文链接:

http://www.nuagenetworks.net/blog/container-networking-standards/