大发welcome

基于Multus CNI

实现Kubernetes容器多网络

大发welcome信息工程院

涂立海

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