深入理解CNI（容器网络接口）
时间：2021-09-24 16:18:41
[导读]CNI简介容器网络的配置是一个复杂的过程，为了应对各式各样的需求，容器网络的解决方案也多种多样，例如有Flannel，Calico，Kube-OVN，Weave等。同时，容器平台/运行时也是多样的，例如有Kubernetes，OpenShift，rkt等。如果每种容器平台都要跟每...
CNI简介
CNI（Container Network Interface）就是这样的一个接口层，它定义了一套接口标准，提供了规范文档以及一些标准实现。采用CNI规范来设置容器网络的容器平台不需要关注网络的设置的细节，只需要按CNI规范来调用CNI接口即可实现网络的设置。
CNI最初是由CoreOS为rkt容器引擎创建的，随着不断发展，已经成为事实标准。目前绝大部分的容器平台都采用CNI标准（rkt，Kubernetes，OpenShift等）。本篇内容基于CNI最新的发布版本v0.4.0。值得注意的是，Docker并没有采用CNI标准，而是在CNI创建之初同步开发了CNM（Container Networking Model）标准。但由于技术和非技术原因，CNM模型并没有得到广泛的应用。CNI是怎么工作的
bandwidth bridge dhcp firewall flannel host-device host-local ipvlan loopback macvlan portmap ptp sbr static tuning vlan
CNI通过JSON格式的配置文件来描述网络配置，当需要设置容器网络时，由容器运行时负责执行CNI插件，并通过CNI插件的标准输入（stdin）来传递配置文件信息，通过标准输出（stdout）接收插件的执行结果。图中的 libcni 是CNI提供的一个go package，封装了一些符合CNI规范的标准操作，便于容器运行时和网络插件对接CNI标准。
举一个直观的例子，假如我们要调用bridge插件将容器接入到主机网桥，则调用的命令看起来长这样：# CNI_COMMAND=ADD 顾名思义表示创建。
# XXX=XXX 其他参数定义见下文。
# < config.json 表示从标准输入传递配置文件
CNI_COMMAND=ADD XXX=XXX ./bridge < config.json
插件入参
容器运行时通过设置环境变量以及从标准输入传入的配置文件来向插件传递参数。
环境变量
-
CNI_COMMAND：定义期望的操作，可以是ADD，DEL，CHECK或VERSION。
-
CNI_CONTAINERID：容器ID，由容器运行时管理的容器唯一标识符。
-
CNI_NETNS：容器网络命名空间的路径。（形如 /run/netns/[nsname]）。
-
CNI_IFNAME：需要被创建的网络接口名称，例如eth0。
-
CNI_ARGS：运行时调用时传入的额外参数，格式为分号分隔的key-value对，例如FOO=BAR;ABC=123
-
CNI_PATH：CNI插件可执行文件的路径，例如/opt/cni/bin。
配置文件
文件示例：{
"cniVersion": "0.4.0", // 表示希望插件遵循的CNI标准的版本。
"name": "dbnet", // 表示网络名称。这个名称并非指网络接口名称，是便于CNI管理的一个表示。应当在当前主机（或其他管理域）上全局唯一。
"type": "bridge", // 插件类型
"bridge": "cni0", // Bridge插件的参数，指定网桥名称。
"ipam": { // IP Allocation Management，管理IP地址分配。
"type": "host-local", // IPAM插件的类型。
// IPAM定义的参数
"subnet": "10.1.0.0/16",
"gateway": "10.1.0.1"
}
} 公共定义部分：
配置文件分为公共部分和插件定义部分。公共部分在CNI项目中使用结构体NetworkConfig定义：type NetworkConfig struct {
Network *types.NetConf
Bytes []byte
}
...
// NetConf describes a network.
type NetConf struct {
CNIVersion string `json:"cniVersion,omitempty"`
Name string `json:"name,omitempty"`
Type string `json:"type,omitempty"`
Capabilities map[string]bool `json:"capabilities,omitempty"`
IPAM IPAM `json:"ipam,omitempty"`
DNS DNS `json:"dns"`
RawPrevResult map[string]interface{} `json:"prevResult,omitempty"`
PrevResult Result `json:"-"`
}
-
cniVersion：表示希望插件遵循的CNI标准的版本。
-
name：表示网络名称。这个名称并非指网络接口名称，是便于CNI管理的一个表示。应当在当前主机（或其他管理域）上全局唯一。
-
type：表示插件的名称，也就是插件对应的可执行文件的名称。
-
Bridge：该参数属于bridge插件的参数，指定主机网桥的名称。
-
IPAM：表示IP地址分配插件的配置，ipam.type则表示IPAM的插件类型。
更详细的信息，可以参考官方文档：https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md#network-configuration
插件定义部分：
上文提到，配置文件最终是传递给具体的CNI插件的，因此插件定义部分才是配置文件的“完全体”。公共部分定义只是为了方便各插件将其嵌入到自身的配置文件定义结构体中，举Bridge插件为例：type NetConf struct {
types.NetConf // <-- 嵌入公共部分
// 底下的都是插件定义部分
BrName string `json:"bridge"`
IsGW bool `json:"isGateway"`
IsDefaultGW bool `json:"isDefaultGateway"`
ForceAddress bool `json:"forceAddress"`
IPMasq bool `json:"ipMasq"`
MTU int `json:"mtu"`
HairpinMode bool `json:"hairpinMode"`
PromiscMode bool `json:"promiscMode"`
Vlan int `json:"vlan"`
Args struct {
Cni BridgeArgs `json:"cni,omitempty"`
} `json:"args,omitempty"`
RuntimeConfig struct {
Mac string `json:"mac,omitempty"`
} `json:"runtimeConfig,omitempty"`
mac string
}
插件操作类型
CNI插件的操作类型只有四种：ADD，DEL，CHECK和VERSION。插件调用者通过环境变量CNI_COMMAND来指定需要执行的操作。
ADD
ADD操作负责将容器添加到网络，或对现有的网络设置做更改。具体地说，ADD操作要么：
-
为容器所在的网络命名空间创建一个网络接口，或者
-
修改容器所在网络命名空间中的指定网络接口
例如通过ADD将容器网络接口接入到主机的网桥中。
其中网络接口名称由CNI_IFNAME指定，网络命名空间由CNI_NETNS指定。
DEL
DEL操作负责从网络中删除容器，或取消对应的修改，可以理解为是ADD的逆操作。具体地说，DEL操作要么：
-
为容器所在的网络命名空间删除一个网络接口，或者
-
撤销ADD操作的修改
例如通过DEL将容器网络接口从主机网桥中删除。
其中网络接口名称由CNI_IFNAME指定，网络命名空间由CNI_NETNS指定。
CHECK
CHECK操作是v0.4.0加入的类型，用于检查网络设置是否符合预期。容器运行时可以通过CHECK来检查网络设置是否出现错误，当CHECK返回错误时（返回了一个非0状态码），容器运行时可以选择Kill掉容器，通过重新启动来重新获得一个正确的网络配置。
VERSION
VERSION操作用于查看插件支持的版本信息。$ CNI_COMMAND=VERSION /opt/cni/bin/bridge
{"cniVersion":"0.4.0","supportedVersions":["0.1.0","0.2.0","0.3.0","0.3.1","0.4.0"]}
链式调用
单个CNI插件的职责是单一的，比如Bridge插件负责网桥的相关配置， Firewall插件负责防火墙相关配置， Portmap插件负责端口映射相关配置。因此，当网络设置比较复杂时，通常需要调用多个插件来完成。CNI支持插件的链式调用，可以将多个插件组合起来，按顺序调用。例如先调用Bridge插件设置容器IP，将容器网卡与主机网桥连通，再调用Portmap插件做容器端口映射。容器运行时可以通过在配置文件设置Plugins数组达到链式调用的目的：{
"cniVersion": "0.4.0",
"name": "dbnet",
"plugins": [
{
"type": "bridge",
// type (plugin) specific
"bridge": "cni0"
},
"ipam": {
"type": "host-local",
// ipam specific
"subnet": "10.1.0.0/16",
"gateway": "10.1.0.1"
}
},
{
"type": "tuning",
"sysctl": {
"net.core.somaxconn": "500"
}
}
]
}
Name string
CNIVersion string
DisableCheck bool
Plugins []*NetworkConfig
Bytes []byte
}
"cniVersion": "0.4.0",
"name": "dbnet",
"type": "bridge",
"bridge": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.1.0.0/16",
"gateway": "10.1.0.1"
}
}
"cniVersion": "0.4.0",
"name": "dbnet",
"type": "tuning",
"sysctl": {
"net.core.somaxconn": "500"
},
"prevResult": { // 调用Bridge插件的返回结果
...
}
}
下载CNI插件
为方便起见，我们直接下载可执行文件：wget https://github.com/containernetworking/plugins/releases/download/v0.9.1/cni-plugins-linux-amd64-v0.9.1.tgz
mkdir -p ~/cni/bin
tar zxvf cni-plugins-linux-amd64-v0.9.1.tgz -C ./cni/bin
chmod x ~/cni/bin/*
ls ~/cni/bin/
bandwidth bridge dhcp firewall flannel host-device host-local ipvlan loopback macvlan portmap ptp sbr static tuning vlan vrfz
示例1——调用单个插件
在示例1中，我们会直接调用CNI插件，为容器设置eth0接口，为其分配IP地址，并接入主机网桥mynet0。跟Docker默认使用的使用网络模式一样，只不过我们将docker0换成了mynet0。启动容器
虽然Docker不使用CNI规范，但可以通过指定--net=none的方式让Docker不设置容器网络。以Nginx镜像为例：contid=$(docker run -d --net=none --name nginx nginx) # 容器ID
pid=$(docker inspect -f '{{ .State.Pid }}' $contid) # 容器进程ID
netnspath=/proc/$pid/ns/net # 命名空间路径
1: lo:
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
接下来我们使用Bridge插件为容器创建网络接口，并连接到主机网桥。创建bridge.json配置文件，内容如下：{
"cniVersion": "0.4.0",
"name": "mynet",
"type": "bridge",
"bridge": "mynet0",
"isDefaultGateway": true,
"forceAddress": false,
"ipMasq": true,
"hairpinMode": true,
"ipam": {
"type": "host-local",
"subnet": "10.10.0.0/16"
}
}
"cniVersion": "0.4.0",
"interfaces": [
....
],
"ips": [
{
"version": "4",
"interface": 2,
"address": "10.10.0.2/16", //给容器分配的IP地址
"gateway": "10.10.0.1"
}
],
"routes": [
.....
],
"dns": {}
}
1: lo:
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
5: eth0@if40:
link/ether c2:8f:ea:1b:7f:85 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.10.0.2/16 brd 10.10.255.255 scope global eth0
valid_lft forever preferred_lft forever
10.10.0.2 last_reserved_ip.0 lock
从主机访问验证
由于mynet0是我们添加的网桥，还未设置路由，因此验证前我们需要先为容器所在的网段添加路由：ip route add 10.10.0.0/16 dev mynet0 src 10.10.0.1 # 添加路由
curl -I 10.10.0.2 # IP换成实际分配给容器的IP地址
HTTP/1.1 200 OK
....
删除容器网络接口
删除的调用入参跟添加的入参是一样的，除了CNI_COMMAND要替换成DEL：CNI_COMMAND=DEL CNI_CONTAINERID=$contid CNI_NETNS=$netnspath CNI_IFNAME=eth0 CNI_PATH=~/cni/bin ~/cni/bin/bridge < bridge.json
在示例2中，我们将在示例1的基础上，使用Portmap插件为容器添加端口映射。
使用cnitool工具
前面的介绍中，我们知道在链式调用过程中，调用方需要转换配置文件，并需要将上一次插件的返回结果插入到本次插件的配置文件中。这是一项繁琐的工作，而libcni已经将这些过程封装好了，在示例2中，我们将使用基于 libcni的命令行工具cnitool来简化这些操作。
示例2将复用示例1中的容器，因此在开始示例2时，请确保已删除示例1中的网络接口。
通过源码编译或go install来安装cnitool：go install github.com/containernetworking/cni/cnitool@latest
配置文件
libcni会读取.conflist后缀的配置文件，我们在当前目录创建portmap.conflist：{
"cniVersion": "0.4.0",
"name": "portmap",
"plugins": [
{
"type": "bridge",
"bridge": "mynet0",
"isDefaultGateway": true,
"forceAddress": false,
"ipMasq": true,
"hairpinMode": true,
"ipam": {
"type": "host-local",
"subnet": "10.10.0.0/16",
"gateway": "10.10.0.1"
}
},
{
"type": "portmap",
"runtimeConfig": {
"portMappings": [
{"hostPort": 8080, "containerPort": 80, "protocol": "tcp"}
]
}
}
]
}
设置容器网络
使用cnitool我们还需要设置两个环境变量：
-
NETCONFPATH：指定配置文件（*.conflist）的所在路径，默认路径为/etc/cni/net.d
-
CNI_PATH：指定CNI插件的存放路径。
删除网络配置
使用cnitool del命令删除容器网络：CNI_PATH=~/cni/bin NETCONFPATH=. cnitool del portmap $netnspath
-
通过JSON配置文件定义网络配置；
-
通过调用可执行程序（CNI插件）来对容器网络执行配置；
-
通过链式调用的方式来支持多插件的组合使用。
下载文档
