深入理解CNI（容器网络接口）

水立方 K8S中文社区

01、 CNI简

容器网络的配置是一个复杂的过程，为了应对各式各样的需求，容器网络的解决方案也多种多样，例如有flannel，calico，kube-ovn，weave等。同时，容器平台/运行时也是多样的，例如有Kubernetes，Openshift，rkt等。如果每种容器平台都要跟每种网络解决方案一一对接适配，这将是一项巨大且重复的工程。当然，聪明的程序员们肯定不会允许这样的事情发生。想要解决这个问题，我们需要一个抽象的接口层，将容器网络配置方案与容器平台方案解耦。

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模型并没有得到广泛的应用。

2、CNI是怎么工作的

CNI的接口并不是指HTTP，gRPC接口，CNI接口是指对可执行程序的调用（exec)。这些可执行程序称之为CNI插件，以K8S为例，K8S节点默认的CNI插件路径为 /opt/cni/bin ，在K8S节点上查看该目录，可以看到可供使用的CNI插件：

$ ls /opt/cni/bin/bandwidth  bridge  dhcp  firewall  flannel  host-device  host-local  ipvlan  loopback  macvlan  portmap  ptp  sbr  static  tuning  vlan

CNI的工作过程大致如下图所示：

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的插件类型。

更详细的信息，可以参考官方文档。

插件定义部分

上文提到，配置文件最终是传递给具体的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"      }    }  ]}

细心的读者会发现，plugins这个字段并没有出现在上文描述的配置文件结构体中。的确，CNI使用了另一个结构体——NetworkConfigList来保存链式调用的配置：

type NetworkConfigList struct {   Name         string   CNIVersion   string   DisableCheck bool   Plugins      []*NetworkConfig    Bytes        []byte}

但CNI插件是不认识这个配置类型的。实际上，在调用CNI插件时，需要将NetworkConfigList转换成对应插件的配置文件格式，再通过标准输入（stdin）传递给CNI插件。例如在上面的示例中，实际上会先使用下面的配置文件调用 bridge 插件：

{  "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"  }}

再使用下面的配置文件调用tuning插件：

{  "cniVersion": "0.4.0",  "name": "dbnet",  "type": "tuning",  "sysctl": {    "net.core.somaxconn": "500"  },  "prevResult": { // 调用bridge插件的返回结果     ...  }}

需要注意的是，当插件进行链式调用的时候，不仅需要对NetworkConfigList做格式转换，而且需要将前一次插件的返回结果添加到配置文件中（通过prevResult字段），不得不说是一项繁琐而重复的工作。不过幸好libcni 已经为我们封装好了，容器运行时不需要关心如何转换配置文件，如何填入上一次插件的返回结果，只需要调用 libcni 的相关方法即可。

3、示例

接下来将演示如何使用CNI插件来为Docker容器设置网络。

下载CNI插件

为方便起见，我们直接下载可执行文件：

wget https://github.com/containernetworking/plugins/releases/download/v0.9.1/cni-plugins-linux-amd64-v0.9.1.tgzmkdir -p  ~/cni/bintar zxvf cni-plugins-linux-amd64-v0.9.1.tgz -C ./cni/binchmod +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

如果你是在K8S节点上实验，通常节点上已经有CNI插件了，不需要再下载，但要注意将后续的 CNI_PATH 修改成/opt/cni/bin。

示例1——调用单个插件

在示例1中，我们会直接调用CNI插件，为容器设置eth0接口，为其分配IP地址，并接入主机网桥mynet0。

跟docker默认使用的使用网络模式一样，只不过我们将docker0换成了mynet0。

启动容器

虽然Docker不使用CNI规范，但可以通过指定 --net=none 的方式让Docker不设置容器网络。以nginx镜像为例：

contid=$(docker run -d --net=none --name nginx nginx) # 容器IDpid=$(docker inspect -f '{{ .State.Pid }}' $contid) # 容器进程IDnetnspath=/proc/$pid/ns/net # 命名空间路径

启动容器的同时，我们需要记录一下容器ID，命名空间路径，方便后续传递给CNI插件。容器启动后，可以看到除了lo网卡，容器没有其他的网络设置：

nsenter -t $pid -n ip a1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000    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

nsenter是namespace enter的简写，顾名思义，这是一个在某命名空间下执行命令的工具。-t表示进程ID, -n表示进入对应进程的网络命名空间。

添加容器网络接口并连接主机网桥

接下来我们使用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"    }}

调用bridge插件ADD操作：

CNI_COMMAND=ADD CNI_CONTAINERID=$contid CNI_NETNS=$netnspath CNI_IFNAME=eth0 CNI_PATH=~/cni/bin ~/cni/bin/bridge < bridge.json

调用成功的话，会输出类似的返回值：

{    "cniVersion": "0.4.0",    "interfaces": [        ....    ],    "ips": [        {            "version": "4",            "interface": 2,            "address": "10.10.0.2/16", //给容器分配的IP地址            "gateway": "10.10.0.1"         }    ],    "routes": [        .....    ],    "dns": {}}

再次查看容器网络设置：

nsenter -t $pid -n ip a1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000    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 forever5: eth0@if40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default    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

可以看到容器中已经新增了eth0网络接口，并在ipam插件设定的子网下为其分配了IP地址。host-local类型的 ipam插件会将已分配的IP信息保存到文件，避免IP冲突，默认的保存路径为/var/lib/cni/network/$NETWORK_NAME：

从主机访问验证

由于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

注意，上述的删除命令并未清理主机的mynet0网桥。如果你希望删除主机网桥，可以执行ip link delete mynet0 type bridge命令删除。

示例2——链式调用

在示例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"}        ]      }    }  ]}

从上述的配置文件定义了两个CNI插件，bridge和portmap。根据上述的配置文件，cnitool会先为容器添加网络接口并连接到主机mynet0网桥上（就跟示例1一样），然后再调用portmap插件，将容器的80端口映射到主机的8080端口，就跟docker run -p 8080:80 xxx一样。

设置容器网络

使用cnitool我们还需要设置两个环境变量：

NETCONFPATH：指定配置文件（*.conflist）的所在路径，默认路径为 /etc/cni/net.d

CNI_PATH ：指定CNI插件的存放路径。

使用cnitool add命令为容器设置网络：

CNI_PATH=~/cni/bin NETCONFPATH=.  cnitool add portmap $netnspath

设置成功后，访问宿主机8080端口即可访问到容器的nginx服务。

删除网络配置

使用cnitool del命令删除容器网络：

CNI_PATH=~/cni/bin NETCONFPATH=.  cnitool del portmap $netnspath

注意，上述的删除命令并未清理主机的mynet0网桥。如果你希望删除主机网桥，可以执行ip link delete mynet0 type bridge命令删除。

4、总结

至此，CNI的工作原理我们已基本清楚。CNI的工作原理大致可以归纳为：

通过JSON配置文件定义网络配置；

通过调用可执行程序（CNI插件）来对容器网络执行配置；

通过链式调用的方式来支持多插件的组合使用。

CNI不仅定义了接口规范，同时也提供了一些内置的标准实现，以及libcni这样的“胶水层”，大大降低了容器运行时与网络插件的接入门槛。

参考

CNI v0.4.0规范文档
CNI master分支规范文档
CNI内置插件文档
cnitool 文档
为什么Kubernetes不使用CNM模型
Introduction to CNI
CNI deep dive

作者：水立方

来源：用户投稿

原文地址：https://juejin.cn/post/6986495816949039141

END

分割线

继续滑动看下一个