基于Multus CNI
實現(xiàn)Kubernetes容器多網(wǎng)絡
神州信息工程院
涂立海
Multus CNI簡單來說是一種符合CNI（Container Network Interface）規(guī)范的開源插件，旨在為實現(xiàn)K8s（Kubernetes） 環(huán)境下容器多網(wǎng)卡而提出的解決方案。它作為一種“元插件”，可以與其他 CNI插件搭配使用。
1.
背景
一個容器啟動后，在默認情況下一般都會只存在兩個虛擬網(wǎng)絡接口（loopback和eth0），而loopback的流量始終都會在本容器內(nèi)或本機循環(huán)，真正對業(yè)務起到支撐作用的只有eth0，當然這對大部分業(yè)務場景而言已經(jīng)能夠滿足。
但是如果一個應用或服務既需要對外提供API調(diào)用服務，也需要滿足自身基于分布式特性產(chǎn)生的數(shù)據(jù)同步，那么這時候一張網(wǎng)卡的性能顯然很難達到生產(chǎn)級別的要求，網(wǎng)絡流量延時、阻塞便成為此應用的一項瓶頸。
基于上述痛點和需求，容器多網(wǎng)絡方案不斷涌現(xiàn)。而根據(jù)開源社區(qū)活躍度、是否實現(xiàn)CNI規(guī)范以及穩(wěn)定性，我們采用multus-cni作為在K8s環(huán)境下的容器多網(wǎng)絡方案。
2.
Multus CNI
Multus CNI enables attaching multiple network interfaces to pods in Kubernetes.
以上是Multus CNI項目官方對其存在意義的精簡描述，它的存在就是幫助K8s的Pod（可簡單理解為一組容器的集合，是K8s可管理的最小“容器”單位）建立多網(wǎng)絡接口。
Multus CNI 本身不提供網(wǎng)絡配置功能，它是通過用其他滿足CNI規(guī)范的插件進行容器的網(wǎng)絡配置。
如圖1所示，在此場景下我們可以把Pod抽象為單個容器。原本容器里應僅存在eth0接口（loopback忽略不計），是由主插件產(chǎn)生創(chuàng)建并配置的；而當集群環(huán)境存在 Multus CNI 插件，并添加額外配置后，將會發(fā)現(xiàn)此容器內(nèi)不再僅有eth0接口，你可以利用這些新增的接口去契合實際業(yè)務需求。
圖1 基于Multus CNI的Pod內(nèi)部網(wǎng)卡結構
前面有提到主插件、元插件，這些究竟代表什么？和Multus CNI有什么關系？要解答這些就繞不開這個問題：什么是 CNI ？
3.
CNI規(guī)范
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是一組限于容器網(wǎng)絡面的規(guī)范，定義了容器網(wǎng)絡資源創(chuàng)建、管理的規(guī)則。
但它并不僅僅是規(guī)范，它也包含了庫和實現(xiàn)，CNI自身實現(xiàn)并提供了內(nèi)置且通用的網(wǎng)絡插件，同時為第三方實現(xiàn)其規(guī)范預留了擴展。
CNI 將插件分成三種類型：
到這里，我們已經(jīng)明白，Multus CNI 屬于Meta類, 它可以與其他第三方插件適配（也就是主插件），主插件來作為Pod的主網(wǎng)絡并且被K8s所感知，它們可以搭配使用且不沖突。
4.
場景規(guī)劃
假設我們已經(jīng)部署好一個K8s高可用集群，使用的主CNI插件是 Calico（其實現(xiàn)已包含Main類型和IPAM類型），元CNI插件是 Multus CNI，但其實Multus本身并沒有實現(xiàn)Main類型和IPAM 類型的功能，它本質(zhì)是個插件的調(diào)用器，所以還需要另外的Main類型和IPAM類型的插件，這里我們選用ipvlan和whereabouts (支持跨集群動態(tài)分配IP地址) 分別作為multus-cni的Main和 IPAM。
同時為解決背景描述的痛點和更貼近生產(chǎn)環(huán)境，下面展示時間案例：實現(xiàn)基于Rook部署Ceph（分布式存儲系統(tǒng)）時實現(xiàn)Ceph 控制面和數(shù)據(jù)面的網(wǎng)絡流量分離。真實生產(chǎn)環(huán)境下，租戶將會在集群內(nèi)產(chǎn)生相當大數(shù)量級的持久性存儲數(shù)據(jù)，而對于分布式存儲必定要滿足高可用特性（即數(shù)據(jù)和服務存在多副本），同步龐大數(shù)量級的存儲數(shù)據(jù)將導致網(wǎng)絡性能的下降，如果控制面網(wǎng)絡和數(shù)據(jù)面網(wǎng)絡使用同一張網(wǎng)卡分發(fā)，也會導致用戶端明顯感知到系統(tǒng)的不穩(wěn)定性。因此網(wǎng)絡分離有益于提高性能以及提升用戶體驗。
如圖2所示，Public Network即是控制面網(wǎng)絡，Cluster Network即是數(shù)據(jù)面網(wǎng)絡；我們忽略Ceph 這些組件的作用和意義，只從網(wǎng)絡流量的流向分析，可以很清晰看出控制面網(wǎng)絡用于Ceph組件內(nèi)部和與外部客戶端進行交互；而數(shù)據(jù)面網(wǎng)絡主要用于副本間的數(shù)據(jù)同步。這就要求同時運行控制網(wǎng)絡和數(shù)據(jù)網(wǎng)絡組件所在的節(jié)點需要有兩張可用的網(wǎng)絡接口。
圖2 Ceph組件網(wǎng)絡流向圖
前面有提到主插件、元插件，這些究竟代表什么？和Multus CNI有什么關系？要解答這些就繞不開這個問題：什么是 CNI ？
5.
落地實踐
有了以上前置知識準備，接下來便可以進行實際的驗證。
集群規(guī)劃六個節(jié)點（僅做測試環(huán)境，生產(chǎn)環(huán)境需重新規(guī)劃），三個控制面節(jié)點，一個LB節(jié)點，一個計算節(jié)點，一個存儲節(jié)點；存儲節(jié)點部署Ceph。
5.1. 部署Multus CNI
獲取Multus CNI資源清單文件，準備鏡像：
因為Multus CNI使用的是 DaemonSet 類型，所以默認在所有節(jié)點都有一個實例，以下Whereabouts 同理。
經(jīng)觀察，Pod運行不久后，將會在各節(jié)點上的/opt/cni/bin/下生成multus的可執(zhí)行文件，/etc/cni/下生成網(wǎng)絡定義文件以及用于配置集群訪問的文件。
可執(zhí)行文件的作用是配置Pod的網(wǎng)絡棧，DaemonSet的作用是實現(xiàn)網(wǎng)絡互通。
注：
一個Network Namespace的網(wǎng)絡棧包括：網(wǎng)卡（Network interface）、回環(huán)設備（Loopback Device）、路由表（Routing Table）和iptables規(guī)則。
打開 00-multus.conf，查看其內(nèi)容：
其中Multus CNI在K8s環(huán)境下的調(diào)用關系如圖3所示，在Kubernetes中，處理容器網(wǎng)絡相關的邏輯并不會在kubelet主干代碼里執(zhí)行，而是會在具體的CRI（Container Runtime Interface，容器運行時接口）實現(xiàn)里完成。CRI將網(wǎng)絡定義文件以JSON格式通過STDIN方式傳遞給Multus CNI插件可執(zhí)行文件。文件中delegates的意義在于Multus會調(diào)用其delegates 指定的插件來執(zhí)行，這里還有一點需要說明下，如果/etc/cni/net.d/ 目錄下有多個網(wǎng)絡定義文件，CRI只會加載按字典順序排在第一位的文件（即插件），即默認情況下創(chuàng)建Pod時使用的是Calico 插件配置網(wǎng)絡。
圖3 Multus調(diào)用鏈
5.2. 部署Whereabouts
獲取Whereabouts 資源清單文件，準備鏡像：
經(jīng)觀察，Pod運行不久后，將會在各節(jié)點上的/opt/cni/bin/ 下生成Whereabouts 的可執(zhí)行文件，/etc/cni/whereabouts.d/下生成網(wǎng)絡定義文件以及用于配置集群訪問的文件。
5.3. 添加 NAD
NAD即NetworkAttachmentDefinition，Multus CNI遵循Kubernetes Network Custom Resource Definition De-facto Standard ，其提供了一種標準化的方法，通過它來指定附加網(wǎng)絡接口的配置。
這里指定了兩個NAD，分別對應控制網(wǎng)絡和數(shù)據(jù)網(wǎng)絡。
• 實際使用的Main類型插件為ipvlan，且默認是L2模式。
• IPAM的功能交給了Whereabouts去做。
• 規(guī)定了網(wǎng)絡號和可以使用的IP范圍（目前使用了同一網(wǎng)段地址，實際生產(chǎn)應做區(qū)分）。
• 控制網(wǎng)絡沒有指定網(wǎng)卡，即使用宿主機默認路由所在網(wǎng)卡。而數(shù)據(jù)網(wǎng)絡一般使用專用網(wǎng)卡，如果需要在多個節(jié)點上部署，需保證數(shù)據(jù)網(wǎng)絡使用的網(wǎng)卡名相同。
ipvlan是Linux內(nèi)核提供的特性，它可以虛擬化宿主接口，ipvlan設備（從設備）共享與宿主接口（主設備）相同的MAC 地址。內(nèi)核驅(qū)動程序通過檢查每個報文的IP地址來決定由哪個虛擬接口來處理該報文。在此L2 模式下，TX處理發(fā)生在附加到從設備上的堆棧實例上，然后將數(shù)據(jù)包切換并排隊到主設備以發(fā)送。在這種模式下，從設備將RX/TX組播和廣播。
5.4. 基于Rook部署Ceph
Rook是采用Operator 模式來部署Ceph的軟件，它負責管理、維護Ceph的生命周期。
接下來從官方地址下載所需的資源清單文件，修改 cluster.yaml，添加Multus CNI多網(wǎng)絡支持。
部署Rook Operator和Ceph：
查看部署結果:
集群規(guī)劃六個節(jié)點（僅做測試環(huán)境，生產(chǎn)環(huán)境需重新規(guī)劃），三個控制面節(jié)點，一個LB節(jié)點，一個計算節(jié)點，一個存儲節(jié)點；存儲節(jié)點部署Ceph。
5.5. 結果驗證
5.5.1 多網(wǎng)絡接口是否已創(chuàng)建
根據(jù)圖2上的展示，只有OSD組件是同時使用了控制網(wǎng)絡和數(shù)據(jù)網(wǎng)絡，可查看OSD Pod信息進行驗證：
現(xiàn)在網(wǎng)卡已正確創(chuàng)建，IP 地址也按預期劃分范圍分配。其中10.244.119.46這個地址是由Calico創(chuàng)建和分配的。
查看存儲節(jié)點IP地址信息：
可以看出使用IPVlan的控制網(wǎng)絡和數(shù)據(jù)網(wǎng)絡的MAC地址和其所在的宿主網(wǎng)卡一致。
同時再確認其他組件是否已創(chuàng)建出多網(wǎng)絡，如MON組件：
5.5.2 Ceph組件間是否能正常通信
• 進入OSD容器網(wǎng)絡命名空間
查看網(wǎng)絡設備：
用OSD組件控制面網(wǎng)絡所在網(wǎng)卡向MON組件控制網(wǎng)絡發(fā)送ICMP報文:
• 進入MON組件網(wǎng)絡命名空間
查看網(wǎng)絡設備：
用MON組件控制面網(wǎng)絡所在網(wǎng)卡向OSD組件控制網(wǎng)絡發(fā)送ICMP報文：
同時用MON組件控制面網(wǎng)絡所在網(wǎng)卡向OSD組件數(shù)據(jù)網(wǎng)絡發(fā)送ICMP報文：
6.
總結
本文選取Multus CNI插件從理論到實踐的角度講述了如何利用Multus CNI在生產(chǎn)環(huán)境下實現(xiàn)容器的多網(wǎng)絡，以及驗證了方案的可行性。
在生產(chǎn)級別環(huán)境下，為了保證穩(wěn)定性和安全性，網(wǎng)絡根據(jù)不同的使用目的進行隔離將是一個必要的措施，比如管理網(wǎng)絡、控制網(wǎng)絡和數(shù)據(jù)網(wǎng)絡的隔離。這種程度的隔離在物理機和虛擬機里面很容易實現(xiàn)，但是在容器網(wǎng)絡里面，例如Kubernetes這樣的容器編排平臺，則會面臨一些限制，尤其是現(xiàn)在Kubernetes的Pod默認還不支持多網(wǎng)絡設置，但是業(yè)界對容器多網(wǎng)絡的需求還是很強烈的。
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
?京公網(wǎng)安備11010802043876
