2. 程式人生 > >DockOne微信分享（六十六）： Docker網路方案初探

DockOne微信分享（六十六）： Docker網路方案初探

阿新 • • 發佈：2019-01-07

【編者的話】這次主要跟大家聊聊Docker的網路方案，首先是現有容器網路方案介紹， 接下來重點講解Calico的特性及技術點，作為引申和對比再介紹下Contiv的特性，最後給出對比測試結果。

隨著容器的火熱發展，數人云越來越多的客戶對容器網路特性要求也開始越來越高，比如：

  • 一容器一IP；
  • 多主機容器互聯；
  • 網路隔離；
  • ACL；
  • 對接SDN等等。

這次主要跟大家聊聊Docker的網路方案，首先是現有容器網路方案介紹， 接下來重點講解Calico的特性及技術點，作為引申和對比再介紹下Contiv的特性, 最後給出對比測試結果。

現有的主要Docker網路方案

首先簡單介紹下現有的容器網路方案，網上也看了好多對比，大家之前都是基於實現方式來分，

隧道方案

通過隧道，或者說Overlay Networking的方式：
  • Weave，UDP廣播，本機建立新的BR，通過PCAP互通。
  • Open vSwitch（OVS），基於VxLAN和GRE協議，但是效能方面損失比較嚴重。
  • Flannel，UDP廣播，VxLan。

隧道方案在IaaS層的網路中應用也比較多，大家共識是隨著節點規模的增長複雜度會提升，而且出了網路問題跟蹤起來比較麻煩，大規模叢集情況下這是需要考慮的一個點。

路由方案

還有另外一類方式是通過路由來實現，比較典型的代表有：
  • Calico，基於BGP協議的路由方案，支援很細緻的ACL控制，對混合雲親和度比較高。
  • Macvlan，從邏輯和Kernel層來看隔離性和效能最優的方案，基於二層隔離，所以需要二層路由器支援，大多數雲服務商不支援，所以混合雲上比較難以實現。

路由方案一般是從3層或者2層實現隔離和跨主機容器互通的，出了問題也很容易排查。

我覺得Docker 1.9以後再討論容器網路方案，不僅要看實現方式，而且還要看網路模型的“站隊”，比如說你到底是要用Docker原生的 “CNM”，還是CoreOS，谷歌主推的“CNI”。

Docker Libnetwork Container Network Model（CNM）陣營

  • Docker Swarm overlay
  • Macvlan & IP network drivers
  • Calico
  • Contiv（from Cisco）

Docker Libnetwork的優勢就是原生，而且和Docker容器生命週期結合緊密；缺點也可以理解為是原生，被Docker“綁架”。

Container Network Interface（CNI）陣營

  • Kubernetes
  • Weave
  • Macvlan
  • Flannel
  • Calico
  • Contiv
  • Mesos CNI

CNI的優勢是相容其他容器技術（e.g. rkt）及上層編排系統（Kuberneres & Mesos)，而且社群活躍勢頭迅猛，Kubernetes加上CoreOS主推；缺點是非Docker原生。

而且從上的也可以看出，有一些第三方的網路方案是“腳踏兩隻船”的， 我個人認為目前這個狀態下也是合情理的事兒，但是長期來看是存在風險的，或者被淘汰，或者被收購。

Calico

接下來重點介紹Calico，原因是它在CNM和CNI兩大陣營都扮演著比較重要的角色。即有著不俗的效能表現，提供了很好的隔離性，而且還有不錯的ACL控制能力。

Calico是一個純3層的資料中心網路方案，而且無縫整合像OpenStack這種IaaS雲架構，能夠提供可控的VM、容器、裸機之間的IP通訊。

通過將整個網際網路的可擴充套件IP網路原則壓縮到資料中心級別，Calico在每一個計算節點利用Linux Kernel實現了一個高效的vRouter來負責資料轉發，而每個vRouter通過BGP協議負責把自己上執行的workload的路由資訊像整個Calico網路內傳播——小規模部署可以直接互聯，大規模下可通過指定的BGP route reflector來完成。

這樣保證最終所有的workload之間的資料流量都是通過IP路由的方式完成互聯的。
1.png
Calico節點組網可以直接利用資料中心的網路結構（無論是L2或者L3），不需要額外的NAT，隧道或者Overlay Network。
2.png
如上圖所示，這樣保證這個方案的簡單可控，而且沒有封包解包，節約CPU計算資源的同時，提高了整個網路的效能。

此外，Calico基於iptables還提供了豐富而靈活的網路Policy，保證通過各個節點上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達性限制等功能。

Calico 架構

3.png
結合上面這張圖，我們來過一遍Calico的核心元件：
  • Felix，Calico Agent，跑在每臺需要執行Workload的節點上，主要負責配置路由及ACLs等資訊來確保Endpoint的連通狀態；
  • etcd，分散式鍵值儲存，主要負責網路元資料一致性，確保Calico網路狀態的準確性；
  • BGP Client（BIRD）, 主要負責把Felix寫入Kernel的路由資訊分發到當前Calico網路，確保Workload間的通訊的有效性；
  • BGP Route Reflector（BIRD），大規模部署時使用，摒棄所有節點互聯的 mesh 模式，通過一個或者多個BGP Route Reflector來完成集中式的路由分發；

Calico Docker Network 核心概念

從這裡開始我們將“站隊” CNM，通過Calico Docker libnetwork plugin的方式來體驗和討論Calico容器網路方案。

先來看一下CNM模型：
4.jpg
從上圖可以知道，CNM基於3個主要概念：
  • Sandbox，包含容器網路棧的配置，包括Interface，路由表及DNS配置，對應的實現如：Linux Network Namespace；一個Sandbox可以包含多個Network；
  • Endpoint，做為Sandbox接入Network的介質，對應的實現如：veth pair、TAP；一個Endpoint只能屬於一個Network，也只能屬於一個Sandbox；
  • Network，一組可以相互通訊的Endpoints；對應的實現如：Linux bridge、VLAN；Network有大量Endpoint資源組成；

除此之外，CNM還需要依賴另外兩個關鍵的物件來完成Docker的網路管理功能，他們分別是：
  • NetworkController，對外提供分配及管理網路的APIs，Docker Libnetwork支援多個活動的網路driver，NetworkController允許繫結特定的driver到指定的網路；
  • Driver，網路驅動對使用者而言是不直接互動的，它通過外掛式的接入來提供最終網路功能的實現；Driver（包括IPAM）負責一個Network的管理，包括資源分配和回收。

有了這些關鍵的概念和物件，配合Docker的生命週期，通過APIs就能完成管理容器網路的功能，具體的步驟和實現細節這裡不展開討論了， 有興趣的可以移步 Github：https://github.com/docker/libn ... gn.md。

接下來再介紹兩個Calico的概念：
  • Pool，定義可用於Docker Network的IP資源範圍，比如：10.0.0.0/8或者192.168.0.0/16；
  • Profile，定義Docker Network Policy的集合，由tags和rules組成；每個 Profile預設擁有一個和Profile名字相同的Tag，每個Profile可以有多個Tag，以List形式儲存。

Profile樣例：
Inbound rules:
1 allow from tag WEB 
2 allow tcp to ports 80,443
Outbound rules:
1 allow

Demo

基於上面的架構及核心概念，我們通過一個簡單的例子，直觀的感受下Calico的網路管理。

Calico以測試為目的叢集搭建，步驟很簡單，這裡不展示了， 大家可以直接參考Github：https://github.com/projectcali ... ME.md。

這裡預設已經有了Calico網路的叢集，IP分別是：192.168.99.102和192.168.99.103。

calicoctl status截圖：
4.png
同時，已經有兩個IP Pool建立好，分別是：10.0.0.0/26和192.168.0.0/16。

calicoctl pool show截圖： 
5.png
當前叢集也已經通過使用calico driver和IPAM建立了不同的Docker Network，本次Demo只需要使用DataMan。

Docker Network ls 截圖： 
6.png
calicoctl profile show截圖： 
7.png
下面我們使用DataMan這個網路，在兩臺slave機器上各啟動一個容器：

數人云下發容器的Marathon json file：
{  "id": "/nginx-calico",
"cmd": null,
"cpus": 0.1,
"mem": 64,
"disk": 0,
"instances": 2,
"container": {
"type": "DOCKER",
"volumes": [],
"docker": {
  "image": "nginx",
  "network": "HOST",
  "privileged": false,
  "parameters": [
    {
      "key": "net",
      "value": "dataman"
    }
  ],
  "forcePullImage": false
}
},
"portDefinitions": [
{
  "port": 10000,
  "protocol": "tcp",
  "labels": {}
}
]
} 

兩臺slave容器IP截圖：
8.png
9.png
從上圖可以看出，兩個slave上的容器IP分別是：slave 10.0.0.48、slave2 192.168.115.193。

Slave容器連通性測試截圖：
10.png
11.png

IP路由實現

12.png
根據上面這個Calico資料平面概念圖，結合我們的例子，我們來看看Calico是如何實現跨主機互通的：

兩臺slave route截圖：
13.png
14.png
對照兩臺slave的路由表，我們就知道，如果slave 1上的容器（10.0.0.48）想要傳送資料到slave 2 上的容器（192.168.115.193）， 那它就會match到最後一條路由規則，將資料包轉發給slave 2（192.168.99.103），那整個資料流就是：
container -> kernel -> (cali2f0e)slave 1 -> one or more hops -> (192.168.99.103)slave 2 -> kernel -> (cali7d73)container

這樣，跨主機的容期間通訊就建立起來了，而且整個資料流中沒有NAT、隧道，不涉及封包。

安全策略ACL

15.png
Calico的ACLs Profile主要依靠iptables和ipset來完成，提供的是可針對每個容器級別的規則定義。

具體的實現我們可以通過iptables命令檢視對應的chain和filter規則, 這裡我們就不展開討論了。

Contiv

http://contiv.github.io

Contiv是Cisco開源出來的針對容器的基礎架構，主要功能是提供基於Policy的網路和儲存管理，是面向微服務的一種新基架。

Contiv能夠和主流的容器編排系統整合，包括：Docker Swarm、Kubernetes、Mesos and Nomad。
16.png
如上圖所示，Contiv比較“誘人”的一點就是，它的網路管理能力，既有L2（VLAN）、L3（BGP），又有 Overlay（VxLAN），而且還能對接Cisco自家的 SDN 產品 ACI。可以說有了它就可以無視底層的網路基礎架構，向上層容器提供一致的虛擬網路了。

Contiv Netplugin特性

  • 多租戶網路混部在同一臺主機上；
  • 整合現有SDN方案；
  • 能夠和非容器環境相容協作，不依賴物理網路具體細節；
  • 即時生效的容器網路Policy/ACL/QoS規則。

網路方案效能對比測試

最後附上我們使用qperf做的簡單效能測試結果，我們選取了vm-to-vm、host、calico-bgp、calico-ipip以及Swarm Overlay進行了對比。

其實Contiv也測試了，但是因為Contiv的測試環境和其他方案使用的不同，不具有直接可比性，所以沒有放入對比圖裡。 直觀感受就是基於OVS的方案確實不理想，後面有時間會統一環境繼續進行測試對比，包括Contiv的L3/L2方案以及引入MacVLAN、Flannel等。

測試環境：VirtualBox VMs，OS：Centos 7.2，kernel 3.10，2 vCPU，2G Mem。

頻寬對比結果如下：
17.png
時延對比結果如下：
18.png
qperf 命令：
# server 端
$ qperf
# client 端
# 持續 10s 傳送 64k 資料包，tcp_bw 表示頻寬，tcp_lat 表示延遲
$ qperf -m 64K -t 10 192.168.2.10 tcp_bw tcp_lat
# 從 1 開始指數遞增資料包大小
$ qperf -oo msg_size:1:64k:*2 192.168.2.10 tcp_bw tcp_lat

總結

隨著容器的落地，網路方案必將成為“兵家”必爭之地，我們 數人云 是輕量級 PaaS 容器叢集管理雲平臺，在網路方案選擇上的考慮是：
  • 效能，Calico和MacVLAN都有著不錯的表現；Contiv L3（BGP）理論上效能也不會差；
  • 普適性，Calico對底層的基本要求就是IP層可達；MacVLAN不適應於公有云；Contiv對底層的相容性可能更好；
  • 可程式設計性，保證整個網路管理過程能夠程式化、API化，這樣方便整合到產品裡，不需要手動運維；Calico和Contiv都有相應的模組；
  • 未來發展，這個就是我說的“站隊”，Docker的CNM和CoreOS、Kubernetes的CNI，現在還看不清，Calico和Contiv都是支援的；

綜上，個人推薦關注和嘗試下Calico或者Contiv做為容器的網路方案，有問題或者收穫，歡迎隨時交流分享。

Q&A

Q：從你發的Marathon json檔案來看，你們是對Mesos底層的網路做了擴充套件嗎？容器網路通過"parameters"傳遞下去的嗎？
A：就是利用Marathon支援的Docker parameters下發，等同於docker run —net dataman xxx。
Q：Felix根據配置的pool地址段配置路由，BGP Client通告路由？請問bgp的鄰居關係是怎麼建立的？是依靠etcd裡的資訊？
A：是的，Felix配置本地Kernel路由，BGP Client負責分發路由資訊；BGP小規模部署採取mesh方式建立，所有節點互聯n^2的聯絡，大規模部署推薦 部署一個或多個BGP route reflector，專門負責路由資訊分發。
Q：請問在DataMan這個網路中路由資訊是如何更新的？我們知道BGP是可以自己發現收斂網路的，那麼在網路控制層面是如何設計的？
A：隨著使用DatMan這個網路的容器的新增或者刪除，Felix負責更新本地路由，BGP client 負責向外分發；Calico的BGP和廣域網的BGP還是有不同，它只是使用private AS num，相對自治，網路控制層面都是可以程式控制的。
Q：請問Calico如何解決多租戶裡地址衝突的問題？
A：多租戶容器混部在同一主機上時，所使用的Network最好不要用同一個Pool裡的就好，這樣就不可能有衝突了。
Q：如果叢集的容器很多，那麼相應的路由表的規則也會增多，這樣會不會對網路效能造成影響？
A：網路效能不會有太大影響，因為容器多流量多網路壓力本來就大，倒是會增加系統負載，畢竟要配置路由規則，同步網路資訊；這部分我們也很關心，但還沒有具體的測試結果。
Q：還有就是路由資訊是存放在etcd中嗎？如何保證路由表的讀取效能和維護路由表的資訊更新？
A：生效的路由肯定是本地的，Endpoint等資訊是在etcd的；這兩個問題都是Calico自身要解決的問題，這部分我們也很關心，但還沒有具體的測試結果；
Q：Calico下跨多個路由hop的情況，中間路由不需要學習這麼多的容器路由表嗎？

相關推薦

DockOne微信分享（六十六）： Docker網路方案初探

【編者的話】這次主要跟大家聊聊Docker的網路方案，首先是現有容器網路方案介紹， 接下來重點講解Calico的特性及技術點，作為引申和對比再介紹下Contiv的特性，最後給出對比測試結果。隨著容器的火熱發展，數人云越來越多的客戶對容器網路特性要求也開始越來越高，比如：

DockOne技術分享（五十七）：Docker容器對儲存的定義（Volume 與 Volume Plugin）

【編者的話】Docker技術自從誕生以來已經帶來了一場雲端計算的革命。其進展速度之快，接受程度之高讓人驚歎。國內已經有不少介紹Docker技術的文章，它的生態，網路，管理，構建，應用都有方方面面的資料。然而，要想在生產環境中部署Docker，開發運維人員必須還要明白do

Java微信公眾平臺開發(十六)--微信網頁授權(OAuth2.0授權)獲取用戶基本信息

php sendget 會話 oauth lsp row code end except 轉自：http://www.cuiyongzhi.com/post/78.html 好長時間沒有寫文章了，主要是最近的工作和生活上的事情比較多而且繁瑣，其實到現在我依然還是感覺有些迷茫

微信分享（微信內建瀏覽器）

轉自：https://blog.csdn.net/kobe088124/article/details/54097593 /**!   * 微信內建瀏覽器的Javascript API，功能包括：  

微信----分享（第三方平臺的授權分享待完善）

參考SDK-----詳情百度網盤 連結：https://pan.baidu.com/s/1ejSw4A5Vi6knL8T9qVQnCQ 提取碼：h8wl 微信文件 ：https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421141115

微信分享（網站）ASP.NET

實現的功能： 1、網址生成二維碼 2、微信掃描二維碼，開啟網址 3、微信APP右上角點選彈出選單分享 4、分享內容可自定義：標題、描述、連結、圖片 普通分享顯示圖： 介面分享顯示圖 微信公眾平臺文件地址：

vue單頁應用history模式下的微信分享（深坑）

之前的專案到我接手時微信分享這個問題已經被處理過了，所以也就偷懶沒有研究了。目前公司專案用的是vue,然後在微信分享這塊也是被坑的很慘了。主要問題在我自己，但我！甩鍋超級厲害！！！技術認輸，甩鍋絕不認輸（滑稽 今天我就要把整個問題的過程記錄一哈，第一次寫部落格

不使用官方SDK,實現微信分享（傳送到朋友，傳送到朋友圈）

發現很多同學發帖說使用微信官方提供的sdk，實現微信分享的過程中遇到問題。我下載了微信的sdk，測試了一下，也失敗了。估計是應用需要通過官方稽核。 既然官方sdk測試不了，那我就使用絕招了：下面便是傳送到朋友，傳送到朋友圈的程式碼。（可以同時傳送圖片和文字感謝@空心糖 的反

[Android分享] 不使用官方SDK,實現微信分享（傳送到朋友，傳送到朋友圈）

本帖最後由 灰塵 於 2013-11-30 14:32 編輯 發現很多同學發帖說使用微信官方提供的sdk,實現微信分享的過程中遇到問題。我下載了微信的sdk,測試了一下，也失敗了。估計是應用需要通過官方稽核。 既然官方sdk測試不了，那我就使用絕招了：下面便是傳送到朋友，傳送到朋友圈的程式碼， [mw_sh

微信分享（配置+開發）簡單流程【只要配置的引數沒問題，就easy】

首先網上查資料，沒有和配置結合，踩了坑（又不愛看官方文件，文字太多一堆口水話）。。。。。整理下自己完整的步驟1、公眾號【基本配置】裡面的【伺服器配置】（下面必須要空降方法，不然配置驗證通不過）一、首先專案匯入公眾號的jar包<!-- 微信公眾號 --> <d

Senparc.Weixin.MP SDK 微信公眾平臺開發教程（二十一）：在小程式中使用 WebSocket （.NET Core）

　　本文將介紹如何在 .NET Core 環境下，藉助 SignalR 在小程式內使用 WebSocket。關於 WebSocket 和 SignalR 的基礎理論知識不在這裡展開，已經有足夠的參考資料，例如參考 SignalR 的官方教程：https://docs.microsoft.com/zh-cn/a

Senparc.Weixin.MP SDK 微信公眾平臺開發教程（二十二）：如何安裝 Nuget(dll) 後使用專案原始碼除錯

　　最近碰到開發者問：我使用 nuget 安裝了 Senparc.Weixin SDK，但是有一些已經封裝好的過程想要除錯，我又不想直接附加原始碼專案，這樣就沒有辦法同步更新了，我應該怎麼辦？ 　　這其實是一個很常見也具有普遍代表性的問題，解決方案也是通用的，本文我們就來學習如何對已經安裝了 dll 的專案

Senparc.Weixin.MP SDK 微信公眾平臺開發教程（二十二）：在 .NET Core 2.0/3.0 中使用 MessageHandler 中介軟體

概述 　　在 《Senparc.Weixin.MP SDK 微信公眾平臺開發教程（六）：瞭解MessageHandler》 中我們已經瞭解了 MessageHandler 的執行原理和使用方法，從我設計了這種處理方式到現在已經 6 年多的時間，這是一種非常穩定而且（在如此複雜環境下）相對易於維護的

OpenCV開發筆記（六十五）：紅胖子8分鐘帶你深入瞭解ORB特徵點（圖文並茂+淺顯易懂+程式原始碼）

若該文為原創文章，未經允許不得轉載原博主部落格地址：https://blog.csdn.net/qq21497936原博主部落格導航：https://blog.csdn.net/qq21497936/article/details/102478062本文章部落格地址：https://blog.csdn.ne

OpenCV開發筆記（六十九）：紅胖子8分鐘帶你使用傳統方法識別已知物體（圖文並茂+淺顯易懂+程式原始碼）

若該文為原創文章，未經允許不得轉載原博主部落格地址：https://blog.csdn.net/qq21497936原博主部落格導航：https://blog.csdn.net/qq21497936/article/details/102478062本文章部落格地址：https://blog.csdn.ne

阿裏雲平臺微信告警（基於收費平臺）

設置 登陸 用戶 升級 div 不能 ges 郵箱 es2017 基於現在大多數人使用微信的眾多性，並且發現當阿裏雲發生告警時，郵箱的報警數太多，（像本人zabbix有郵箱告警，zabbix分經典網絡和專有網絡的報警，還有物理機的告警，都是分開平臺監控的。）所以想到能不能把

那些年用node接入微信走過的坑之（五）---微信選單（自動回覆素材）

序言 之前在第二篇上，寫了如何生成選單，發現寫的不夠完善，在這一篇補上自動回覆訊息和自動回覆圖文 第一步：建立選單 這裡要注意一點是選單的type為’click’，而不是’view’，view只能進行頁面跳轉。 { "type": "c

php微信支付（僅Jsapi支付）詳細步驟.----僅適合第一次做微信開發的程式設計師

本人最近做了微信支付開發,是第一次接觸.其中走了很多彎路,遇到的問題也很多.為了讓和我一樣的新人不再遇到類似的問題,我把我的開發步驟和問題寫出來,以供參考. 開發時間是2016/8/2,所以微信支付的版本也是對應此時的版本. 一.前期準備： 首先你們公司開通微信支付功能後

java微信支付（統一下訂單）

微信支付統一下訂單： 微信公眾號配置共五個地方： 1、設定key：微信商戶平臺——賬戶設定——API安全——金鑰設定 2、頁面授權域名：用來過的openID，公眾號設定——功能設定——設定【網頁授權域名】（【js安全域名】【業務域名】也一併設定了吧） 3、設定支付

優雅程式設計之Guava瓜娃工具類的7點整理學習分享（三十九）

開心一笑 【面試官：“熟悉哪種語言”。 應聘者：“JAVA”。 面試官：“知道什麼叫類麼”。 應聘者：“我這人實在，工作努力，不知道什麼叫累”。 面試官：“知道什麼是包？”。 應聘者：“我這人實在 平常不帶包 也不用公司準備了”。 面試官：“知道