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