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

　　CNI 标准规范接口，包含了添加、检查、验证、删除网络等接口■■，并提供了按列表或单个进行网络配置的两组接口，方便用户灵活使用。

　　K8s 网络模型采用 CNI(Container Network Interface, 容器网络接口) 协议，只要提供一个标准的接口，就能为同样满足该协议的所有容器平台提供网络功能。

　　kubelet 在 Node 节点上负责 Pod 的创建、销毁◆★★★◆、监控上报等核心流程，通过 Cobra 命令行解析参数启动二进制可执行文件★■★。

　　CNI 从容器管理系统(dockershim) 处获取运行时信息(Container Runtime)，包括 network namespace 的路径■■，容器 ID 以及 network interface name■★，再从容器网络的配置文件中加载网络配置信息，再将这些信息传递给对应的插件★■◆■★★，由插件进行具体的网络配置工作，并将配置的结果再返回到容器管理系统中。

　　Meta 插件：由 CNI 社区维护的内置 CNI 插件，不能作为独立的插件使用■★，需要调用其他插件。tuning★■★，是一个通过 sysctl 调整网络设备参数的二进制文件■★■；portmap，是一个通过 iptables 配置端口映射的二进制文件；bandwidth，是一个使用 Token Bucket Filter (TBF) 来进行限流的二进制文件◆■■。

　　K8s 网络模型采用 CNI(Container Network Interface, 容器网络接口) 协议，只要提供一个标准的接口★◆◆◆◆◆，就能为同样满足该协议的所有容器平台提供网络功能。CNI 目前已被众多开源项目所采用★◆◆■■，同时也是一个 CNCF(Cloud Native Computing Foundation) 项目。可以预见，CNI 将会成为未来容器网络的标准。

　　Libnetwork 是 CNM 的原生实现★■★◆★。它为 Docker daemon 和网络驱动程序之间提供了接口★◆◆。网络控制器负责将驱动和一个网络进行对接■◆★■■。每个驱动程序负责管理它所拥有的网络以及为该网络提供的各种服务◆★◆■■■，例如 IPAM 等等。由多个驱动支撑的多个网络可以同时并存★★■◆。原生驱动包括 none, bridge, overlay 以及 MACvlan。

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

　　本文通过分析 K8s 中 kubelet 启动◆■■、Pod 创建/删除、Docker 创建/删除 Container、CNI RPC 调用、容器网络配置等核心流程，对 CNI 实现机制进行了解析，通过源码、图文方式说明了相关流程逻辑，以期更好的理解 K8s CNI 运行流程。

　　但是★★◆，container runtime 会在不同情况下使用到不同的插件，这带来了复杂性。另外，CNM 需要使用分布式存储系统来保存网络配置信息★◆■■■★，例如 etcd。

　　一个容器可以被加入到被不同插件所驱动的多个网络之中◆◆◆。一个网络有自己对应的插件和唯一的名称。CNI 插件需要提供两个命令：ADD 用来将网络接口加入到指定网络，DEL 用来将其移除。这两个接口分别在容器被创建和销毁的时候被调用。

　　用户若要编写自己的 CNI 插件，则可专注于实现图中这些 RPC 接口即可◆■★◆■★，然后可以与官方维护的三类基础插件自由组合，形成多种多样的容器网络解决方案。

　　接着，会调用 CNI 接口 SetUpPod 进行相关网络配置与启动，此时建立起来的容器网络■■◆■◆，就可以直接用于之后创建的业务容器如 initContainers、containers 进行共享网络。

　　进入 K8s 的世界◆◆★■★，会发现有很多方便扩展的 Interface，包括 CNI◆★■, CSI, CRI 等，将这些接口抽象出来，是为了更好的提供开放、扩展★■、规范等能力。