CNI 簡介

不管是 docker 還是 kubernetes，在網絡方面目前都沒有一個完美的、終極的、普適性的解決方案，不同的用戶和企業因為各種原因會使用不同的網絡方案。目前存在網絡方案 flannel、calico、openvswitch、weave、ipvlan等，而且以后一定會有其他的網絡方案，這些方案接口和使用方法都不相同，而不同的容器平臺都需要網絡功能，它們之間的適配如果沒有統一的標準，會有很大的工作量和重復勞動。

CNI 就是這樣一個標準，它旨在為容器平臺提供網絡的標準化。不同的容器平臺（比如目前的 kubernetes、mesos 和 rkt）能夠通過相同的接口調用不同的網絡組件。

CNI(Conteinre Network Interface) 是 google 和 CoreOS 主導制定的容器網絡標準，它 本身并不是實現或者代碼，可以理解成一個協議。這個標準是在?rkt 網絡提議?的基礎上發展起來的，綜合考慮了靈活性、擴展性、ip 分配、多網卡等因素。

這個協議連接了兩個組件：容器管理系統和網絡插件。它們之間通過 JSON 格式的文件進行通信，實現容器的網絡功能。具體的事情都是插件來實現的，包括：創建容器網絡空間（network namespace）、把網絡接口（interface）放到對應的網絡空間、給網絡接口分配 IP 等等。

關于網絡，docker 也提出了 CNM 標準，它要解決的問題和 CNI 是重合的，也就是說目前兩者是競爭關系。目前 CNM 只能使用在 docker 中，而 CNI 可以使用在任何容器運行時。CNM 主要用來實現 docker 自身的網絡問題，也就是?docker network?子命令提供的功能。

官方網絡插件

所有的標準和協議都要有具體的實現，才能夠被大家使用。CNI 也不例外，目前官方在 github 上維護了同名的?CNI?代碼庫，里面已經有很多可以直接拿來使用的 CNI 插件。

官方提供的插件目前分成三類：main、meta 和 ipam。main 是主要的實現了某種特定網絡功能的插件；meta 本身并不會提供具體的網絡功能，它會調用其他插件，或者單純是為了測試；ipam 是分配 IP 地址的插件。

ipam 并不提供某種網絡功能，只是為了靈活性把它單獨抽象出來，這樣不同的網絡插件可以根據需求選擇 ipam，或者實現自己的 ipam。

這些插件的功能說明如下：

• main
  • loopback：這個插件很簡單，負責生成?lo?網卡，并配置上?127.0.0.1/8?地址
  • bridge：和 docker 默認的網絡模型很像，把所有的容器連接到虛擬交換機上
  • macvlan：使用 macvlan 技術，從某個物理網卡虛擬出多個虛擬網卡，它們有獨立的 ip 和 mac 地址
  • ipvlan：和 macvlan 類似，區別是虛擬網卡有著相同的 mac 地址
  • ptp：通過 veth pair 在容器和主機之間建立通道
• meta
  • flannel：結合 bridge 插件使用，根據 flannel 分配的網段信息，調用 bridge 插件，保證多主機情況下容器
• ipam
  • host-local：基于本地文件的 ip 分配和管理，把分配的 IP 地址保存在文件中
  • dhcp：從已經運行的 DHCP 服務器中獲取 ip 地址

接口參數

網絡插件是獨立的可執行文件，被上層的容器管理平臺調用。網絡插件只有兩件事情要做：把容器加入到網絡以及把容器從網絡中刪除。調用插件的數據通過兩種方式傳遞：環境變量和標準輸入。一般插件需要三種類型的數據：容器相關的信息，比如 ns 的文件、容器 id 等；網絡配置的信息，包括網段、網關、DNS 以及插件額外的信息等；還有就是 CNI 本身的信息，比如 CNI 插件的位置、添加網絡還是刪除網絡。

我們來看一下為容器添加網絡是怎么工作的，刪除網絡和它過程一樣。

把容器加入到網絡

調用插件的時候，這些參數會通過環境變量進行傳遞：

• CNI_COMMAND：要執行的操作，可以是?ADD（把容器加入到某個網絡）、DEL（把容器從某個網絡中刪除）
• CNI_CONTAINERID：容器的 ID，比如 ipam 會把容器 ID 和分配的 IP 地址保存下來。可選的參數，但是推薦傳遞過去。需要保證在管理平臺上是唯一的，如果容器被刪除后可以循環使用
• CNI_NETNS：容器的 network namespace 文件，訪問這個文件可以在容器的網絡 namespace 中操作
• CNI_IFNAME：要配置的 interface 名字，比如?eth0
• CNI_ARGS：額外的參數，是由分號;分割的鍵值對，比如 “FOO=BAR;hello=world”
• CNI_PATH：CNI 二進制查找的路徑列表，多個路徑用分隔符?:?分隔

網絡信息主要通過標準輸入，作為 JSON 字符串傳遞給插件，必須的參數包括：

• cniVersion：CNI 標準的版本號。因為 CNI 在演化過程中，不同的版本有不同的要求
• name：網絡的名字，在集群中應該保持唯一
• type：網絡插件的類型，也就是 CNI 可執行文件的名稱
• args：額外的信息，類型為字典
• ipMasq：是否在主機上為該網絡配置 IP masquerade
• ipam：IP 分配相關的信息，類型為字典
• dns：DNS 相關的信息，類型為字典

插件接到這些數據，從輸入和環境變量解析到需要的信息，根據這些信息執行程序邏輯，然后把結果返回給調用者，返回的結果中一般包括這些參數：

• IPs assigned to the interface：網絡接口被分配的 ip，可以是 IPv4、IPv6 或者都有
• DNS 信息：包含 nameservers、domain、search domains 和其他選項的字典

CNI 協議的內容還在不斷更新，請到官方文檔獲取當前的信息。

CNI 的特性

CNI 作為一個協議/標準，它有很強的擴展性和靈活性。如果用戶對某個插件有額外的需求，可以通過輸入中的?args?和環境變量?CNI_ARGS?傳輸，然后在插件中實現自定義的功能，這大大增加了它的擴展性；CNI 插件把 main 和 ipam 分開，用戶可以自由組合它們，而且一個 CNI 插件也可以直接調用另外一個 CNI 插件，使用起來非常靈活。

如果要實現一個繼承性的 CNI 插件也不復雜，可以編寫自己的 CNI 插件，根據傳入的配置調用 main 中已經有的插件，就能讓用戶自由選擇容器的網絡。

在 kubernetes 中的使用

CNI 目前已經在 kubernetes 中開始使用，也是目前官方推薦的網絡方案，具體的配置方法可以參考kubernetes 官方文檔。

kubernetes 使用了 CNI 網絡插件之后，工作過程是這樣的：

• kubernetes 先創建 pause 容器生成對應的 network namespace
• 調用網絡 driver（因為配置的是 CNI，所以會調用 CNI 相關代碼）
• CNI driver 根據配置調用具體的 cni 插件
• cni 插件給 pause 容器配置正確的網絡
• pod 中其他的容器都是用 pause 的網絡

參考資料

• CNI spec 文檔
• Linux Network namespaces and CNI
• The container networking landscape: cni from coreos and cnm from docker
• CNI and OCI

總結

以上是生活随笔為你收集整理的CNI：容器网络接口详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。