CNI：容器網絡接口

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

http://cizixs.com/2017/05/23/container-network-cni