詳解: Docker原生網路和主流最佳化方案

       在雲端計算架構設計中，最複雜且最重要的元件就是網路，Docker作為雲端計算追捧的新寵兒也不會例外，尤其是當使用Docker容器構建分散式服務時，通訊和網路變得非常重要。

 

開篇之前，先給讀者分享下筆者對容器知識總結: 容器技術架構、網路和生態詳解，內容涉及容器技術的方方面面，感興趣的讀者可通文末“閱讀原文”過瞭解詳情。

 

第1章 容器演進和關鍵技術介紹 4

第2章 為什麼是Docker引領主流 13

第3章 詳談Docker的生態系統 34

• 3.1 Docker的生態系統導圖 35

• 3.2 Docker的挑戰者Rocket 37

第4章 詳解Docker AUFS技術 38

第5章 Docker技術架構詳細分析 44

• 5.1 Docker關鍵技術回顧 44
• 5.2 Docker實現持續部署 45
• 5.3 Docker總架構圖 46
• 5.3.1 Docker Client模組 48
• 5.3.2 Docker Daemon模組 49
• 5.3.3 Docker Server子模組 50
• 5.3.4 Engine子模組 52
• 5.3.5 Job任務子模組 52
• 5.3.6 Docker Registry模組 53
• 5.3.7 Graph模組 53
• 5.3.8 Driver模組 54
• 5.3.9 Libcontainer模組 58
• 5.3.10 Docker container模組 60

第6章 容器定義儲存(CDS)技術分析 61

第7章 Portworx容器定義儲存(CDS)詳解 70

• 7.1 Portworx架構和原理 71

• 7.2 儲存控制面 72

• 7.3 資料面訪問 73

• 7.4 生命週期管理 74

• 7.5 Portworx應用場景 75

第8章 Diamanti容器融合儲存基礎架構 78

• 8.1 容器的內建基礎架構 79
• 8.2 容器與其網路互聯 80
• 8.3 容器的儲存持久化 81
• 8.4 簡化容器管理 81
• 8.5 整合流行的容器開源架構 82
• 8.6 Diamanti產品特點 83

第9章 Docker原生網路和實現原理 84

第10章 Openstack如何實現與容器對接 88

第11章 Docker網路技術方案詳解 94

• 11.1 Libnetwork方案介紹 95
• 11.2 Pipework方案介紹 97
• 11.3 Socketplane方案介紹 98
• 11.4 Weave方案介紹 99
• 11.5 Flannel方案介紹 100
• 11.6 Tinc方案介紹 101

第12章 細說Docker發展和生態 102

• 12.1 Docker發展歷程 102

• 12.2 Docker的推動者 103

• 12.3 Docker映象倉庫 103

• 12.4 Docker的生態環境 104

• 12.5 Docker的優勢 104

• 12.6 Docker的跨平臺特性 106

• 12.7 Docker容器雲 106

• 12.8 Docker改名Moby淺析 107

 

接下來，我們將從Docker原生網路架構出發，討論目前活躍的多種針對Docker提出的網路最佳化方案。

 

      Docker的網路是基於Linux的網路名稱空間和虛擬網路裝置(特別是veth pair)來實現。在Docker中，網路介面預設都是虛擬的介面，可以充分發揮資料在不同Docker間或Docker與宿主機轉發效率。這是因為Linux透過在核心中透過資料複製實現虛擬介面之間的資料轉發，即傳送介面的傳送快取中的資料包將被直接複製到接收介面的接收快取中，而無需透過外部物理網路裝置進行交換。

 

      Docker容器建立網路時，會在本地主機和容器內分別建立一個虛擬介面，並讓它們彼此連通，形成一對虛擬網路介面，這樣的一對介面叫做veth pair。

 

 

     當Docker行程啟動之後，它會配置一個叫docker0的虛擬網橋在宿主機上。這個網橋介面允許Docker去分配虛擬的子網給即將啟動的容器。這個網橋在容器內的網路和宿主機網路之間將作為網路介面的主節點呈現。

 

      當Docker容器啟動後，建立一對虛擬介面，分別放到本地主機和新容器的名稱空間中。本地宿主機一端的虛擬介面連線到預設的docker0網橋或指定網橋上，並具有一個以veth開頭的唯一名字。容器一端的虛擬介面將放到新建立的容器中，並修改名字作為eth0，這個介面只在容器的名稱空間可見。

 

      從網橋可用地址段中，分配一個網橋子網內的IP地址給容器的eth0。這個IP地址嵌在容器內網路中，用於提供容器網路到宿主機docker0網橋上的一個通道。並配置預設路由閘道器為docker0網絡卡的內部介面docker0的IP地址。Docker會自動配置iptables規則和配置NAT，便於連通宿主機上的docker0網橋。完成這些操作之後，容器就可以使用它所能看到的eth0虛擬網絡卡，來連線其他容器和訪問外部網路。

 

      Docker提供了一種容器間通訊機制叫做Docker links。如果一個新容器連結到一個已有容器，新容器將會透過環境變數獲得已有容器的連結資訊。透過提供給信任容器有關已有容器的連結資訊，實現容器間的通訊。

  

    同一宿主機上的容器可以相互通訊並提供服務給相鄰容器，而不需要額外的配置(埠暴露或釋出)，宿主系統會簡單將路由請求從docker0傳到目的地。

 

      容器可以暴露它們的埠給宿主機，用於接收外部請求流量。暴露出的埠可以透過特定埠或由Docker來隨機選擇一個高位空閑埠對映到宿主機上。暴露埠意味著Docker將呈現該埠是暴露容器所使用，這可以被用於服務發現和links(新容器將會設定環境變數來對應原容器暴露的埠)。

 

      容器可以釋出它們的埠給宿主機，埠釋出將對映埠到宿主介面，使得它可以與外界互動。暴露出的埠可選擇對映宿主機上一個指定埠，或者Docker可以自動的隨機選擇一個高位空閑埠。

 

      Libcontainer也需要重點關註下，它是Docker中用於容器管理模組(建立容器、實現容器生命週期管理)，它基於Go語言實現，透過管理Namespaces、Cgroups以及檔案系統來進行容器控制。在Docker中，對容器管理的模組為Execdriver，目前Docker支援的容器管理方式有兩種，一種就是最初支援的LXC方式，另一種稱為Native的Libcontainer進行容器管理。

 

     Docker起初是採用LXC的開源容器管理引擎。把LXC複雜的容器建立與使用方式簡化為Docker自己的一套命令體系。後來Docker將底層實現都抽象化到Libcontainer的介面。這樣可以實現跨平臺能力，無論是使用了Namespace、Cgroups技術或是使用Systemd等其他方案，只要實現了Libcontainer定義的一組標準介面，Docker都可以執行。

 

      Docker原生網路模型在保證埠對映、連結正確的情況下，可實現同一宿主機上容器間的通訊和宿主機之間的通訊。

 

但針對安全或者特殊功能要求特殊的網路環境，Docker這個原生的網路功能就會受限制。於是許多專案致力於擴充套件Docker網路生態。下麵我們重點介紹下這些基於Docker網路最佳化的6個專案及方案。

Libnetwork方案介紹

      Libnetwork是Docker公司正在開發的新的網路底層架構，由libcontainer和Docker Engine中的網路相關的程式碼合併而成。Libnetwork的標的是引入了容器網路模型(CNM)，併為應用程式提供一致的程式設計API介面以及網路抽象。CNM得到了網路方面的合作伙伴Cisco、IBM、Joyent、Microsoft、Rancher、VMware和Weave的支援，使Libnetwork發展為一個跨平臺的容器網路管理工具。

 

      Libnetwork的容器網路模型包含了三個重要概念，Network Sandbox，Endpoint和Network。

 

 

     網路沙盒Network Sandbox承載Docker容器中一個網路配置的隔離、獨立執行環境。Endpoint用於在某個網路上進行網路通訊的介面，一個Endpoint只能加入一個network Sandbox，同時，多個Endpoint也可以在一個網路沙盒中共存。

 

Network就是一個唯一的、可識別的endpoint組，組內endpoint可以相互通訊。不同網路組內的endpoint不能通訊。可以建立兩個完全隔離的Frontend network和Backend network。

Pipework方案介紹

 

      Pipework是由Docker開發者透過Shell開發，作為一個權宜之計來簡化Docker網路配置流程，這個專案使得高階網路配置變得容易，能夠自動完成一些網路功能配置，但功能有限。

 

     Pipework首先會檢查是否存在br0網橋，若不存在，就自己建立。若”ovs”開頭，就會建立OpenVswitch網橋，以”br”開頭，建立Linux網橋。建立veth pair裝置，用於為容器提供網絡卡並連線到br0網橋。

 

      使用Docker inspect找到容器在主機中的pid，然後透過PID將容器的網路名稱空間連結到/var/run/netns/目錄下。這麼做的目的是，方便在主機上使用ip netns命令配置容器的網路。將之前建立的veth pair裝置分別加入容器和網橋中(在容器中預設為eth1)。

 

      最後會配置新網絡卡eth1的IP。若指定為閘道器地址，那麼pipework會改變預設路由eth0和docker0為該IP，容器通往外網的流量會經由新配置的eth1出去。

 

Socketplane方案介紹

 

      Socketplane是SND創業公司，目前已經被Docker公司收購，其實現方式是在原有的Docker命令上做了一層封裝，透過攔截並修改Docker Client傳送給Docker engine的命令來實現網路安全和維護的目前。

 

     Socketplane依賴於OpenvSwitch和Consul。Socketplane作為虛擬交換機實現底層網路通訊，Consul實現訊息同步和服務發現。SocketPlane在 Socket 層面提供了一個網路的抽象層，對開發者遮蔽VLANs, VXLANs, Tunnels 或TEPs等概念，實現和OpenvSwitch整合，支援多網路和分散式 IP 地址管理，透過可管理的方式去解決各種網路問題。

 

Weave方案介紹

 

      Weave方案包含兩大元件，使用者態Shell指令碼和Weave虛擬路由容器。Weave虛擬路由容器需要在每個宿主機上佈置，把不同宿主機的route容器連線起來。

 

     不同主機間的網路通訊依賴於Weave虛擬route，透過route攔截所有普通容器的IP請求，以UDP資料包傳送到其他宿主機上的普通容器，實現跨主機的多個容器扁平網路。但是Weave解決了不同主機網路間通訊問題。

 

Flannel方案介紹 

 

      Flannel原名為Rudder，是由CoreOS團隊開發，這個專案被開發的初衷是為每一個宿主系統提供一個共享、完整的網路子網，配合Google kubernetes使用，但在其他場景下也被用來簡化埠對映和網路管理的複雜性。

 

 

      Flannel和OpenvSwitch設計思路基本一致，在Docker在宿主機上建立一個網橋時，透過採用Flannel自己的網橋替代它。其差別在於Flannel通訊是用軟的UDP來包裝IP資料包，而OpenvSwitch用的是採用SDN思想。Flannel網路配置是寫入到etcd叢集中，Flannel行程一般執行在三臺主機上，Docker啟動時，執行的Docker從主機所屬的完整子網網段中動態分配IP。

 

Tinc方案介紹

 

      Tinc是一個輕量的VPN軟體，也是一個開源的VPN解決方案，它採用隧道和加密實現。Tinc是一個健壯的解決方案，它能夠使私有網路對任何應用透明。

 

 

     關於Tinc方案介紹的資料並不多，主要藉助VPN技術實現資料網路安全傳輸，由於採用了“虛擬專用網”技術，即使用者實際上並不存在一個獨立專用的網路，也能保證Docker間資料安全傳輸。

 

      Docker容器本身具備對內或對外提供服務是原生網路模型和能力，如透過虛擬介面的配置、子網、NAT表管理和iptables等，但是還需要一些網路專案支援，提供了更高階的網路配置和安全控制。