040.集群网络-CNI网络模型

一 CNM网络模型

1.1 网络模型

生产环境中，跨主机容器间的网络互通已经成为基本要求，更高的要求包括容器固定IP地址、一个容器多个IP地址、多个子网隔离、ACL控制策略、与SDN集成等。目前主流的容器网络模型主要有Docker公司提出的Container Network Model（CNM）模型和CoreOS公司提出的Container Network Interface（CNI）模型。

1.2 CNM模型

CNM模型是由Docker公司提出的容器网络模型，现在已经被Cisco Contiv、Kuryr、Open Virtual Networking（OVN）、Project Calico、VMware、Weave和Plumgrid等项目所采纳。同时，Weave、Project Calico、Kuryr和Plumgrid等项目也为CNM提供了网络插件的具体实现。

CNM模型主要通过Network Sandbox、Endpoint和Network这3个组件进行实现，如下图所示：

Network Sandbox：容器内部的网络栈，包括网络接口、路由表、DNS等配置的管理。Sandbox可用Linux网络命名空间、FreeBSD Jail等机制进行实现。一个Sandbox可以包含多个Endpoint。

Endpoint：用于将容器内的Sandbox与外部网络相连的网络接口。可以使用veth对、OpenvSwitch的内部port等技术进行实现。一个Endpoint仅能够加入一个Network。

Network：可以直接互连的Endpoint的集合。可以通过Linux网桥、VLAN等技术进行实现。一个Network包含多个Endpoint。

二 CNI模型

2.1 CNI模型

CNI是由CoreOS公司提出的另一种容器网络规范，现在已经被Kubernetes、rkt、ApacheMesos、CloudFoundry和Kurma等项目采纳。另外,Contiv Networking,Project Calico、Weave、SR-IOV、Cilium、Infoblox、Multus、Romana、Plumgrid和Midokura等项目也为CNI提供网络插件的具体实现。

如上所示，容器运行环境与各种网络插件通过CNI进行连接的模型。

CNI定义的是容器运行环境与网络插件之间的简单接口规范，通过一个JSON Schema定义CNI插件提供的输入和输出参数。一个容器可以通过绑定多个网络插件加入多个网络中。本节将对Kubernetes如何实现CNI模型进行详细说明。

2.2 CNI规范概述

CNI提供了一种应用容器的插件化网络解决方案，定义对容器网络进行操作和配置的规范，通过插件的形式对CNI接口进行实现。CNI是由rkt Networking Proposal发展而来的，试图提供一种普适的容器网络解决方案。

CNI仅关注在创建容器时分配网络资源，和在销毁容器时删除网络资源，这使得CNI规范非常轻巧、易于实现，得到了广泛的支持。在CNI模型中只涉及两个概念：容器和网络。

容器（Container）：是拥有独立Linux网络命名空间的环境，例如使用Docker或rkt创建的容器。容器需要拥有自己的Linux网络命名空间，这是加入网络的必要条件。

网络（Network）：表示可以互连的一组实体，这些实体拥有各自独立、唯一的IP地址，可以是容器、物理机或者其他网络设备（比如路由器）等。

对容器网络的设置和操作都通过插件（Plugin）进行具体实现，CNI插件包括两种类型：CNI Plugin和IPAM（IP Address Management）Plugin。CNI Plugin负责为容器配置网络资源，IPAM Plugin负责对容器的IP地址进行分配和管理。IPAM Plugin作为CNI Plugin的一部分，与CNIPlugin协同工作。

2.3 CNI Plugin插件详解

CNI Plugin包括3个基本接口的定义：添加（ADD）、删除（DELETE）、检查（CHECK）和版本查询（VERSION）。这些接口的具体实现要求插件提供一个可执行的程序，在容器网络添加或删除时进行调用，以完成具体的操作。

添加：将容器添加到某个网络。主要过程为在Container Runtime创建容器时，先创建好容器内的网络命名空间（Network Namespace），然后调用CNI插件为该netns进行网络配置，最后启动容器内的进程。添加接口的参数如下：

• Version：CNI版本号。
• ContainerID：容器ID。
• Network Namespace path：容器的网络命名空间路径，例如/proc/[pid]/ns/net。
• Network configuration：网络配置JSON文档，用于描述容器待加入的网络。
• Extra arguments：其他参数，提供基于容器的CNI插件简单配置机制。
• Name of the interface inside the container：容器内的网卡名，返回的信息如下：
• Interfaces list：网卡列表，根据Plugin的实现，可能包括Sandbox Interface名称、主机Interface名称、每个Interface的地址等信息。
• IPs assigned to the interface：IPv4或者IPv6地址、网关地址、路由信息等。
• DNS information：DNS相关的信息。

删除：容器销毁时将容器从某个网络中删除。删除接口的参数如下：

• Version：CNI版本号。
• ContainerID：容器ID。
• Network Namespace path：容器的网络命名空间路径，例如/proc/[pid]/ns/net。
• Network configuration：网络配置JSON文档，用于描述容器待加入的网络。
• Extra arguments：其他参数，提供基于容器的CNI插件简单配置机制。
• Name of the interface inside the container：容器内的网卡名。

检查：检查容器网络是否正确设置。检查接口的参数如下：

• Version：CNI版本号。
• ContainerID：容器ID。
• Network Namespace path：容器的网络命名空间路径，例如/proc/[pid]/ns/net。
• Network configuration：网络配置JSON文档，用于描述容器待加入的网络。
• Extra arguments：其他参数，提供基于容器的CNI插件简单配置机制。
• Name of the interface inside the container：容器内的网卡名

版本查询：查询网络插件支持的CNI规范版本号。无参数，返回值为网络插件支持的CNI规范版本号。

2.4 IPAM Plugin插件详解

为了减轻CNI Plugin对IP地址管理的负担，在CNI规范中设置了一个新的插件专门用于管理容器的IP地址（还包括网关、路由等信息），被称为IPAM Plugin。通常由CNI Plugin在运行时自动调用IPAM Plugin完成容器IP地址的分配。

IPAM Plugin负责为容器分配IP地址、网关、路由和DNS，典型的实现包括host-local和dhcp。与CNI Plugin类似，IPAM插件也通过可执行程序完成IP地址分配的具体操作。IPAM可执行程序也处理传递给CNI插件的环境变量和通过标准输入（stdin）传入的网络配置参数。

如果成功完成了容器IP地址的分配，则IPAM插件应该通过标准输出（stdout）返回以下JSON报文：

  1 ｛
  2     "cniVersion": "0.4.0",
  3     "ips":[
  4           {
  5
  6                    "version": "<4-or-6>",
  7                     "address": "<ip-and-prefix-in-CIDR>",
  8                     "gateway": "<ip-address-of-the-gateway>" (optional)
  9            },
 10            ..........
 11       ],
 12       "routes":[
 13        {
 14           "dst": "<ip-and-prefix-in-cidr>",
 15            "gw": "<ip-of-next-hop>"
 16         },
 17        ........
 18       ]
 19
 20       "dns":{
 21        "nameservers": <list-of-nameservers> (optional)
 22        "domain": <name-of-local-domain>  (optional)
 23        "search": <list-of-options>  (optional)
 24      }
 25 ｝

其中包括ips、routes和dns三段内容：

• ips段：分配给容器的IP地址（也可能包括网关）。
• routes段：路由规则记录。
• dns段：DNS相关的信息。

2.5 多网络插件

多网络插件参考：https://blog.csdn.net/qq_31136839/article/details/99852616

三 Kubernetes网络插件

3.1 Kubernetes网络插件

Kubernetes目前支持两种网络插件的实现。

CNI插件：根据CNI规范实现其接口，以与插件提供者进行对接。

kubenet插件：使用bridge和host-local CNI插件实现一个基本的cbr0。

为了在Kubernetes集群中使用网络插件，需要在kubelet服务的启动参数上设置下面两个参数：

• --network-plugin-dir：kubelet启动时扫描网络插件的目录。
• --network-plugin：网络插件名称，对于CNI插件，设置为cni即可，无须关注--network-plugin-dir的路径。对于kubenet插件，设置为kubenet，目前仅实现了一个简单的cbr0 Linux网桥。

在设置--network-plugin="cni"时，kubelet还需设置下面两个参数。

• --cni-conf-dir：CNI插件的配置文件目录，默认为/etc/cni/net.d。该目录下配置文件的内容需要符合CNI规范。
• --cni-bin-dir：CNI插件的可执行文件目录，默认为/opt/cni/bin。

目前已有多个开源项目支持以CNI网络插件的形式部署到Kubernetes集群中，进行Pod的网络设置和网络策略的设置，包括Calico、Canal、Cilium、Contiv、Flannel、Romana、WeaveNet等。