容器網絡聚焦：CNM和CNI

小貼士

容器的網絡技術突飛猛進。業界逐漸聚焦到Docker的CNM和CoreOS的CNI。

目前關於Linux容器網絡接口的配置有兩種的可能的標準：容器網絡模型（CNM）和容器網絡接口（CNI）。網絡是至關複雜的，並且提供某種功能的方式也多種多樣。

在斟酌某項技術的時候，咱們須要考慮採納的成本；是否會增長對供應商的依賴。社區的採納程度和支持程度也是比較重要的考量。插件開發者還須要考慮哪一種方式相對比較容易實現。

Container Network Model(CNM)

CNM是一個被 Docker 提出的規範。如今已經被Cisco Contiv, Kuryr, Open Virtual Networking (OVN), Project Calico, VMware 和 Weave 這些公司和項目所採納。

Libnetwork是CNM的原生實現。它爲Docker daemon和網絡驅動程序之間提供了接口。網絡控制器負責將驅動和一個網絡進行對接。每一個驅動程序負責管理它所擁有的網絡以及爲該網絡提供的各類服務，例如IPAM等等。由多個驅動支撐的多個網絡能夠同時並存。網絡驅動能夠按提供方被劃分爲原生驅動(libnetwork內置的或Docker支持的)或者遠程驅動 (第三方插件)。原生驅動包括 none, bridge, overlay 以及 MACvlan。驅動也能夠被按照適用範圍被劃分爲本地（單主機）的和全局的 (多主機）。

『Network Sandbox』- 一個容器內部的網絡棧。

『Endpoint』- 一個一般成對出現的網絡接口。一端在網絡容器內，另外一端在網絡內。 一個Endpoints能夠加入一個網絡。一個容器能夠有多個endpoints。

『Network』-一個endpoints的集合。該集合內的全部endpoints能夠互聯互通。

最後，CNM還支持標籤(labels)。Lable是以key-value對定義的元數據。用戶能夠經過定義label這樣的元數據來自定義libnetwork和驅動的行爲。

Container Network Interface(CNI)

CNI是由CoreOS提出的一個容器網絡規範。已採納改規範的包括Apache Mesos, Cloud Foundry, Kubernetes, Kurma 和 rkt。另外 Contiv Networking, Project Calico 和 Weave這些項目也爲CNI提供插件。

CNI 的規範比較小巧。它規定了一個容器runtime和網絡插件之間的簡單的契約。這個契約經過JSON的語法定義了CNI插件所須要提供的輸入和輸出。

一個容器能夠被加入到被不一樣插件所驅動的多個網絡之中。一個網絡有本身對應的插件和惟一的名稱。CNI 插件須要提供兩個命令：一個用來將網絡接口加入到指定網絡，另外一個用來將其移除。這兩個接口分別在容器被建立和銷燬的時候被調用。

CNI Flow

容器runtime首先須要分配一個網絡命名空間以及一個容器ID。而後連同一些CNI配置參數傳給網絡驅動。接着網絡驅動會將該容器鏈接到網絡並將分配的IP地址以JSON的格式返回給容器runtime。

Mesos 是最新的加入CNI支持的項目。Cloud Foundry的支持也正在開發中。當前的Mesos網絡使用宿主機模式，也就是說容器共享了宿主機的IP地址。Mesos正在嘗試爲每一個容器提供一個本身的IP地址。這樣作的目的是使得IT人員能夠自行選擇適合本身的組網方式。

目前，CNI的功能涵蓋了IPAM, L2 和 L3。端口映射(L4)則由容器runtime本身負責。CNI也沒有規定端口映射的規則。這樣比較簡化的設計對於Mesos來說有些問題。端口映射是其中之一。另一個問題是：當CNI的配置被改變時，容器的行爲在規範中是沒有定義的。爲此，Mesos在CNI agent重啓的時候，會使用該容器與CNI關聯是的配置。

CNI和CNM

這種模塊化驅動的方式可與說對運維人員更有吸引力。由於運維人員能夠比較靈活的選擇適合現有模式的驅動。兩種方案都提供了獨立的擴展點，也就是插件的接口。這使得網絡驅動能夠建立、配置和鏈接網絡。也使得IPAM能夠配置，發現和管理IP地址。這種分離讓編排變得容易。

CNM 模式下的網絡驅動不能訪問容器的網絡命名空間。這樣作的好處是libnetwork能夠爲衝突解決提供仲裁。一個例子是：兩個獨立的網絡驅動提供一樣的靜態路由配置，可是卻指向不一樣的下一跳IP地址。與此不一樣，CNI容許驅動訪問容器的網絡命名空間。CNI正在研究在相似狀況下如何提供仲裁。

CNI支持與第三方IPAM的集成，能夠用於任何容器runtime。CNM從設計上就僅僅支持Docker。因爲CNI簡單的設計，許多人認爲編寫CNI插件會比編寫CNM插件來得簡單。

這些模型增進了系統的模塊化，增長了用戶的選擇。也促進了第三方網絡插件以創新來提供更高級的網絡功能。

總結

容器網絡領域隨着供應商和各類項目的不斷變化而變化。有些被合併，例如Docker兼併SocketPlan；Flannel到Tigera的遷移 - Tigera的Canal將Calico和Flannel兩個項目組合在一塊兒了。 CoreOS會繼續爲Flannel提供支持，而且會將Canal集成在它們的企業級Kubernetes方案 - Tectonic 裏面。同時，新的發佈版本也帶來新的變化。Docker 1.12中包括的underlay和load-balancing等新特性，也將該項目的網絡支持提高到新的高度。

雖然在容器網絡方面有各類各樣的技術，咱們值得慶幸的是（至少是如今）容器生態圈基本上聚焦在這兩個模型上。開發人員和運維人員都但願可以最終自動化網絡配置。在沒能徹底自動配置以前，解決方案之一是一些人工參與的預先配置好的資源。好比運維人員能夠預先分配一些網絡，包括IP地址空間，IPAM，QoS等等。開發人員能夠根據本身應用的須要來從中選擇網絡。

微信搜索：Wise2C ∣ 一個有趣的公衆號