K8s中的CNI网络模型

1. 网络模型

1.1 CNM

容器中的网络模型早年有CNM(Container Network Model, 容器网络模型) ，是一个由Docker提出的规范。
CNM中有代表性的就是Libnetwork，在Docker daemon和网络驱动之间提供接口，网络控制器负责将驱动和网络进行连接。
CNM的问题：
● 容器运行时有不同的插件，运行复杂
● 需要使用分布式存储来保存网络配置模型

● Network Sandbox：容器内部的网络栈，包括网络接口、路由表、DNS 等配置的管理。Sandbox 可用 Linux 网络命名空间、FreeBSD Jail 等机制进行实现。一个 Sandbox 可以包含多个 Endpoint。
● Endpoint：用于将容器内的 Sandbox 与外部网络相连的网络接口。可以使用 vethpair、Open vSwitch 的内部 port 等技术进行实现。一个 Endpoint 仅能够加入一个 Network。
● Network：可以直接互连的 Endpoint 的集合。可以通过 Linux bridge、VLAN 等技术进行实现。一个 Network 包含多个 Endpoint。

1.2 CNI

相比起CNM，CNI不需要通过分布式存储系统来存放网络配置信息，而只需要使用json。

● Loopback：lo设备
● Bridge：网桥
● IPVlan：创建VLAN，共享MAC地址，但IP地址不同
● PTP：veth Pair设备
CNI中有两个命令ADD和DEL，分别是添加和一处网络接口。这两个接口在容器创建时使用
CNI中的三类插件

其中Main是用来创建具体网络的二进制文件；Meta不是独立的插件，需要调用其他插件；IPAM是IP Address Manage的缩写，是用来分配容器中IP地址的二进制文件。

2. CNI的使用

2.1 CNI的配置

CNI插件的配置通过在./etc/cni/net.d中放置配置文件配置。下图是通过这种方式配置的flannel和portmap插件。
需要注意的是，K8s不支持多个CNI插件混用。如果在文件夹下放置了多个CNI插件配置文件，只会显示第一个。

2.2 CNI插件加载原理

插件配置的实质是加载项目脚本，生成二进制文件。CNI插件的生效简而言之便是：Container Runtime在创建容器进程前，先创建一个NetWork Namespace，使用CNI插件对这个NS进行网络配置，配置完成后再启动容器进程。

/pkg/kubelet/kubelet.go中的PreInitRuntimeService()，先会读取CNI配置，然后启动一个gRPC监听client，当有容器时间发生时便会创建Pod

之后进行Pod的创建，然后通过CNI接口建立容器网络。cni.go中的SetUpPod被调用便可在容器创建时进行网络配置
需要注意的是。在v1.20以前的K8s中，容器运行时是通过docker_shim创建的。但是在v1.24中，docker_shim已经被废弃了。随之而来的就是K8s不再支持对CNI插件的管理。但可以通过使用Containered部署K8s集群。
K8s v1.24中已经没有了docker_shim