在这里插入图片描述
参考 https://zhuanlan.zhihu.com/p/563710712

深入理解容器网络接口(CNI)

1、 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的工作过程大致如下图所示：

aaa
![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/8005c08f476b4bc390d916f547524655.png)

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.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


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


示例1——调用单个插件


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


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

启动容器


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



contid=KaTeX parse error: Expected 'EOF', got '#' at position 47: …e nginx nginx) #̲ 容器ID
pid=(docker inspect -f ‘{{ .State.Pid }}’ KaTeX parse error: Expected 'EOF', got '#' at position 9: contid) #̲ 容器进程ID
netnspa…pid/ns/net # 命名空间路径


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



nsenter -t KaTeX parse error: Expected 'EOF', got '&' at position 20: …-n ip a
1: lo: &̲lt;LOOPBACK,UP,…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 KaTeX parse error: Expected 'EOF', got '&' at position 20: …-n ip a
1: lo: &̲lt;LOOPBACK,UP,…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=
        
         
          
           
            c
           
           
            o
           
           
            n
           
           
            t
           
           
            i
           
           
            d
           
           
            C
           
           
            N
           
           
            
             I
            
            
             N
            
           
           
            E
           
           
            T
           
           
            N
           
           
            S
           
           
            =
           
          
          
           contid CNI_NETNS=
          
         
        contidCNIN​ETNS=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的工作原理大致可以归纳为：



  

  1. 

   
  2. 通过JSON配置文件定义网络配置
      
    

      
       
    

      
    
    ；

  3. 

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

  5. 

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

  7. 

  



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



参考:



  

  • 

   
  • CNI v0.4.0规范文档

  • 

   
  • CNI master分支规范文档

  • 

   
  • CNI内置插件文档

  • 

   
  • cnitool 文档

  • 

   
  • 为什么Kubernetes不使用CNM模型

  • 

   
  • Introduction to CNI

  • 

   
  • CNI deep dive

  •




发布于 2022-09-12 22:07





容器网络



# kubernetes # docker # 容器
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

cover

开源鸿蒙 Flutter 实战｜搜索功能页面完整实现指南

avatar 开源鸿蒙跨平台开发者社区

《从零构建 OpenHarmony 兼容应用：Dio 网络请求集成指南》

本文将介绍基于 Flutter for OpenHarmony 的应用开发全流程，涵盖开发环境配置、依赖安装、多语言国际化实现以及在 DevEco 虚拟机上的部署运行。模块技术栈功能Flask 后端多语言国际化 API 服务Flutter 前端Dart + Dio数据清单展示与网络请求功能模块实现详情数据模型DataItem 类，支持 JSON 序列化网络请求Dio 库封装，支持超时处理和错误捕获

avatar 开源鸿蒙跨平台开发者社区

Flutter+三方库+鸿蒙入门实战：设备信息+网络请求Demo

本文基于DevEco Studio 6.0 + OpenHarmony SDK 20，先讲解Flutter鸿蒙开发核心基础、三方库适配原理，再带你从零完成一个可直接运行的Flutter鸿蒙实战案例，集成鸿蒙适配版三方库，包含设备信息获取、网络请求、界面展示，新手可一步步跟着操作，全程无复杂操作，快速入门Flutter+三方库+鸿蒙应用开发。

avatar 开源鸿蒙跨平台开发者社区