J9集团

基于Multus CNI

实现Kubernetes容器多网络

J9集团信息工程院

涂立海

Multus CNI单一来说是一种切合CNI（Container Network Interface）规范的开源插件
，旨在为实现K8s（Kubernetes） 环境下容器多网卡而提出的解决规划
。它作为一种“元插件”
，能够与其他 CNI插件搭配使用
。

1.

布景

一个容器启动后
，在默认情况下通常城市只存在两个虚构网络接口（loopback和eth0）
，而loopback的流量始终城市在本容器内或本机循环
，真正对业务起到支持作用的只有eth0
，当然这对大部门业务场景而言已经可能满足
。

但是若是一个利用或服务既必要对表提供API挪用服务
，也必要满足自身基于散布式个性产生的数据同步
，那么这时辰一张网卡的机能显然很难达到出产级此外要求
，网络流量延时、阻塞便成为此利用的一项瓶颈
。

基于上述痛点和需要
，容器多网络规划不休涌现
。而凭据开源社区活跃度、是否实现CNI规范以及不变性
，我们选取multus-cni作为在K8s环境下的容器多网络规划
。

2.

Multus CNI

Multus CNI enables attaching multiple network interfaces to pods in Kubernetes.

以上是Multus CNI项目官方对其存在意思的精简描述
，它的存在就是援手K8s的Pod（可单一理解为一组容器的集中
，是K8s可治理的最幼“容器”单元）成立多网络接口
。

Multus CNI 自身不提供网络配置职能
，它是通过用其他满足CNI规范的插件进行容器的网络配置
。

如图1所示
，在此场景下我们能够把Pod抽象为单个容器
。正本容器里应仅存在eth0接口（loopback忽略不计）
，是由主插件产生创建并配置的；而当集群环境存在 Multus CNI 插件
，并增长额表配置后
，将会发现此容器内不再仅有eth0接口
，你能够利用这些新增的接口去符合现实业务需要
。

图1 基于Multus CNI的Pod内部网卡结构

前面有提到主插件、元插件
，这些到底代表什么？和Multus CNI有什么关系？要解答这些就绕不开这个问题：什么是 CNI ？

3.

CNI规范

CNI (Container Network Interface), a Cloud Native Computing Foundation project, consists of a specification and libraries for writing plugins to configure network interfaces in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing allocated resources when the container is deleted. Because of this focus, CNI has a wide range of support and the specification is simple to implement.

以上引用了官方对其的描述
，简短来讲CNI是一组限于容器网络面的规范
，界说了容器网络资源创建、治理的规定
。

但它并不仅仅是规范
，它也蕴含了库和实现
，CNI自身实现并提供了内置且通用的网络插件
，同时为第三方实显熹规范预留了扩大
。

CNI 将插件分成三种类型：

到这里
，我们已经领略
，Multus CNI 属于Meta类, 它能够与其他第三方插件适配（也就是主插件）
，主插件来作为Pod的主网络并且被K8s所感知
，它们能够搭配使用且不矛盾
。

4.

场景规划

如果我们已经部署好一个K8s高可用集群
，使用的主CNI插件是 Calico（其实现已蕴含Main类型和IPAM类型）
，元CNI插件是 Multus CNI
，但其实Multus自身并没有实现Main类型和IPAM 类型的职能
，它性质是个插件的挪用器
，所以还必要另表的Main类型和IPAM类型的插件
，这里我们选用ipvlan和whereabouts (支持跨集群动态分配IP地址) 别离作为multus-cni的Main和 IPAM
。

同时为解决布景描述的痛点和更切近出产环境
，下面展示功夫案例：实现基于Rook部署Ceph（散布式存储系统）时实现Ceph 节造面和数据面的网络流量分离
。真实出产环境下
，租户将会在集群内产生相当大数量级的悠久性存储数据
，而对于散布式存储注定要满足高可用个性（即数据和服务存在多副本）
，同步重大数量级的存储数据将导致网络机能的降落
，若是节造面网络和数据面网络使用统一张网卡分发
，也会导致用户端显著感知到系统的不不变性
。因而网络分离有益于提高机能以及提升用户履历
。

如图2所示
，Public Network即是节造面网络
，Cluster Network即是数据面网络；我们忽略Ceph 这些组件的作用和意思
，只从网络流量的流向分析
，能够很清澈看出节造面网络用于Ceph组件内部和与表部客户端进行交互；而数据面网络重要用于副本间的数据同步
。这就要求同时运行节造网络和数据网络组件地点的节点必要有两张可用的网络接口
。

图2 Ceph组件网络流向图

前面有提到主插件、元插件
，这些到底代表什么？和Multus CNI有什么关系？要解答这些就绕不开这个问题：什么是 CNI ？

5.

落地实际

有了以上前置知识筹备
，接下来便能够进行现实的验证
。

集群规划六个节点（仅做测试环境
，出产环境需沉新规划）
，三个节造面节点
，一个LB节点
，一个推算节点
，一个存储节点；存储节点部署Ceph
。

5.1. 部署Multus CNI

获取Multus CNI资源清单文件
，筹备镜像：

由于Multus CNI使用的是 DaemonSet 类型
，所以默认在所有节点都有一个事俘
，以下Whereabouts 同理
。

经观察
，Pod运行不久后
，将会在各节点上的/opt/cni/bin/下天生multus的可执行文件
，/etc/cni/下天生网络界说文件以及用于配置集群接见的文件
。

可执行文件的作用是配置Pod的网络栈
，DaemonSet的作用是实现网络互通
。

注：

一个Network Namespace的网络栈蕴含：网卡（Network interface）、回环设备（Loopback Device）、路由表（Routing Table）和iptables规定
。

打开 00-multus.conf
，查看其内容：

其中Multus CNI在K8s环境下的挪用关系如图3所示
，在Kubernetes中
，处置容器网络有关的逻辑并不会在kubelet主干代码里执行
，而是会在具体的CRI（Container Runtime Interface
，容器运行时接口）实现里实现
。CRI将网络界说文件以JSON体式通过STDIN方式传递给Multus CNI插件可执行文件
。文件中delegates的意思在于Multus会挪用其delegates 指定的插件来执行
，这里还有一点必要注明下
，若是/etc/cni/net.d/ 目录下有多个网络界说文件
，CRI只会加载按字典挨次排在第一位的文件（即插件）
，即默认情况下创建Pod时使用的是Calico 插件配置网络
。

图3 Multus挪用链

5.2. 部署Whereabouts

获取Whereabouts 资源清单文件
，筹备镜像：

经观察
，Pod运行不久后
，将会在各节点上的/opt/cni/bin/ 下天生Whereabouts 的可执行文件
，/etc/cni/whereabouts.d/下天生网络界说文件以及用于配置集群接见的文件
。

5.3. 增长 NAD

NAD即NetworkAttachmentDefinition
，Multus CNI遵循Kubernetes Network Custom Resource Definition De-facto Standard
，其提供了一种尺度化的步骤
，通过它来指定附加网络接口的配置
。

这里指定了两个NAD
，别离对应节造网络和数据网络
。

• 现实使用的Main类型插件为ipvlan
，且默认是L2模式
。

• IPAM的职能交给了Whereabouts去做
。

• 划定了网络号和能够使用的IP领域（目前使用了统一网段地址
，现实出产应做分辨）
。

• 节造网络没有指定网卡
，即便用宿主机默认路由地点网卡
。而数据网络通常使用专用网卡
，若是必要在多个节点上部署
，需保障数据网络使用的网卡名一样
。

ipvlan是Linux内核提供的个性
，它能够虚构化宿主接口
，ipvlan设备（从设备）共享与宿主接口（主设备）一样的MAC 地址
。内核驱动法式通过查抄每个报文的IP地址来决定由哪个虚构接口来处置该报文
。在此L2 模式下
，TX处置产生在附加到从设备上的仓库事俘上
，而后将数据包切换并列队到主设备以发送
。在这种模式下
，从设备将RX/TX组播和广播
。

5.4. 基于Rook部署Ceph

Rook是选取Operator 模式来部署Ceph的软件
，它掌管治理、守护Ceph的性命周期
。

接下来从官方地址下载所需的资源清单文件
，批改 cluster.yaml
，增长Multus CNI多网络支持
。

部署Rook Operator和Ceph：

查看部署了局:

集群规划六个节点（仅做测试环境
，出产环境需沉新规划）
，三个节造面节点
，一个LB节点
，一个推算节点
，一个存储节点；存储节点部署Ceph
。

5.5. 了局验证

5.5.1 多网络接口是否已创建

凭据图2上的展示
，只有OSD组件是同时使用了节造网络和数据网络
，可查看OSD Pod信息进行验证：

此刻网卡已正确创建
，IP 地址也按预期划分领域分配
。其中10.244.119.46这个地址是由Calico创建和分配的
。

查看存储节点IP地址信息：

能够看出使用IPVlan的节造网络和数据网络的MAC地址和其地点的宿主网卡一致
。

同时再确认其他组件是否已创建出多网络
，如MON组件：

5.5.2 Ceph组件间是否能正常通讯

• 进入OSD容器网络定名空间

查看网络设备：

用OSD组件节造面网络地点网卡向MON组件节造网络发送ICMP报文:

• 进入MON组件网络定名空间

查看网络设备：

用MON组件节造面网络地点网卡向OSD组件节造网络发送ICMP报文：

同时用MON组件节造面网络地点网卡向OSD组件数据网络发送ICMP报文：

6.

总结

本文拔取Multus CNI插件从理论到实际的角度讲述了若何利用Multus CNI在出产环境下实现容器的多网络
，以及验证了规划的可行性
。

在出产级别环境下
，为了保障不变性和安全性
，网络凭据分歧的使用主张进行隔离将是一个必要的措施
，好比治理网络、节造网络和数据网络的隔离
。这种水平的隔离在物理机和虚构机里面很容易实现
，但是在容器网络里面
，例如Kubernetes这样的容器编排平台
，则会晤对一些限度
，尤其是此刻Kubernetes的Pod默认还不支持多网络设置
，但是业界对容器多网络的需要还是很强烈的
。

7.

参考资料

Multus-CNI

Container Network Interface (CNI) Specification

CNI Plugins Overview

The Kubernetes network model

Kubernetes CNI

whereabouts

IPVLAN Driver HOWTO

Rook Cluster CRD

Ceph NETWORK CONFIGURATION REFERENCE