CNI插件把main和ipam分开，为用户提供了自由组合它们的机制，甚至一个CNI插件也可以直接调用另外一个插件。CNI项目中有两个代码仓库：一个是提供用于开发CNI网络插件的库文件libcni，以及命令行工具cnitool的containernetworking/cni；另一个是CNI内置插件程序containernetworking/plugins。
CNI还支持使用plugins字段组合多个CNI网络插件依次进行网络配置，以实现将核心网络管理插件和meta插件等相组合，以堆叠出一个完整的解决方案。各插件以列表形式依次定义，前一个插件的配置结果将传递给后一个插件，直到列表中的所有插件都成功配置完成。
CNI规范负责连接容器管理系统和网络插件两类组件，它们之间通过JSON格式的文件进行通信，以完成容器网络管理。具体的管理操作均由插件来实现，包括创建容器netns（网络名称空间）、关联网络接口到对应的netns，以及给网络接口分配IP等。
Flannel：由CoreOS提供的CNI网络插件，也是最简单、最受欢迎的网络插件；它使用VXLAN或UDP协议封装IP报文来创建Overlay网络，并借助etcd维护网络的分配信息，同一节点上的Pod间通信可基于本地虚拟网桥（cni0）进行，而跨节点的Pod间通信则要由flanneld守护进程封装隧道协议报文后，通过查询etcd路由到目的地；Flannel也支持host-gw路由模型。
Calico：同Flannel一样广为流行的CNI网络插件，以灵活、良好的性能和网络策略所著称。Calico是路由型CNI网络插件，它在每台机器上运行一个vRouter，并基于BGP路由协议在节点之间路由数据包。Calico支持网络策略，它借助iptables实现访问控制功能。另外，Calico也支持IPIP型的Overlay网络。
Canal：由Flannel和Calico联合发布的一款统一网络插件，它试图将二者的功能集成在一起，由前者提供CNI网络插件，由后者提供网络策略。
WeaveNet：由Weaveworks提供的CNI网络插件，支持网络策略。WeaveNet需要在每个节点上部署vRouter路由组件以构建起一个网格化的TCP连接，并通过Gossip协议来同步控制信息。在数据平面上，WeaveNet通过UDP封装实现L2隧道报文，报文封装支持两种模式：一种是运行在用户空间的sleeve（套筒）模式，另一种是运行在内核空间的fastpath（快速路径）模式，当网络拓扑不适合fastpath模式时，Weave将自动切换至sleeve模式。
Multus CNI：多CNI插件，实现了CNI规范的所有参考类插件（例如Flannel、MAC VLAN、IPVLAN和DHCP等）和第三方插件（例如Calico、Weave和Contiv等），也支持Kubernetes中的SR-IOV、DPDK、OVS-DPDK和VPP工作负载，以及Kubernetes中的云原生应用程序和基于NFV的应用程序，是需要为Pod创建多网络接口时的常用选择。
Antrea：一款致力于成为Kubernetes原生网络解决方案的CNI网络插件，它使用OpenvSwitch构建数据平面，基于Overlay网络模型完成Pod间的报文交换，支持网络策略，支持使用IPSec ESP加密GRE隧道流量。
DAMM：由诺基亚发布的电信级的CNI网络插件，支持具有高级功能的IP VLAN模式，内置IPAM模块，可管理多个集群范围内的不连续三层网络；支持通过CNImeta插件将网络管理功能委派给任何其他网络插件。
kube-router：kube-router是Kubernetes网络的一体化解决方案，它可取代kube-proxy实现基于ipvs的Service，能为Pod提供网络，支持网络策略以及拥有完美兼容BGP协议的高级特性。
选择网络插件时应该基于底层系统环境限制、容器网络的功能需求和性能需求3个重要的评估标准来衡量插件的适用性。
- 底层系统环境限制：公有云环境多有自己专有的实现，例如Google GCE、AzureCNI、AWS VPC CNI和Aliyun Terway等，它们通常是相应环境上较佳的选择。若虚拟化环境限制较多，除Overlay网络模型别无选择，则可用的方案有FlannelVXLAN、Calico IPIP、Weave和Antrea等。物理机环境几乎支持任何类型的网络插件，此时一般应该选择性能较好的Calico BGP、Flannel host-gw或DAMM IPVLAN等。
- 容器网络功能需求：支持NetworkPolicy的解决方案以Calico、WeaveNet和Antrea为代表，而且后两个支持节点到节点间的通信加密。而大量Pod需要与集群外部资源互联互通时，应该选择Underlay网络模型一类的解决方案。
- 容器网络性能需求：Overlay网络中的协议报文有隧道开销，性能略差，而Underlay网络则几乎不存这方面的问题，但Overlay或Underlay路由模型的网络插件支持较快的Pod创建速度，而Underlay模型中的IP VLAN或MAC VLAN模式则较慢。
