理解Docker（6）：若干企業生產環境中的容器網絡方案

本文轉載自查看原文 2016-10-02 05:58 9321 Docker/ 網絡/ 行業

本系列文章將介紹 Docker的相關知識：

（1）Docker 安裝及基本用法

（2）Docker 鏡像

（3）Docker 容器的隔離性 - 使用 Linux namespace 隔離容器的運行環境

（4）Docker 容器的隔離性 - 使用 cgroups 限制容器使用的資源

（5）Docker 網絡

（6）若干企業生產環境中的容器網絡方案

Docker 在早期只有單機上的網絡解決方案，在 1.19 版本引入了原生的 overlay 網絡解決方案，但是它的性能損耗較大，可能無法適應一些生產環境的要求。除了Docker 提供的解決方案外，還有其它一些開源的解決方案。本文首先會簡介各種已有的方案，然后根據公開分享的資料，總結一下部分企業在生產環境中對容器網絡的選型和考量。

1. 現有的跨主機容器網絡解決方案

1.1 Flannel容器網絡

Flannel 是由 CoreOS 主導的解決方案。Flannel 為每一個主機的 Docker daemon 分配一個IP段，通過 etcd 維護一個跨主機的路由表，容器之間 IP 是可以互相連通的，當兩個跨主機的容器要通信的時候，會在主機上修改數據包的 header，修改目的地址和源地址,經過路由表發送到目標主機后解包。封包的方式，可以支持udp、vxlan、host-gw等，但是如果一個容器要暴露服務，還是需要映射IP到主機側的。

1.2 Calico 網絡方案

Calico 是個年輕的項目，基於BGP協議，完全通過三層路由實現。Calico 可以應用在虛機，物理機，容器環境中。在Calico運行的主機上可以看到大量由 linux 路由組成的路由表，這是calico通過自有組件動態生成和管理的。這種實現並沒有使用隧道，沒有NAT，導致沒有性能的損耗，性能很好，從技術上來看是一種很優越的方案。這樣做的好處在於，容器的IP可以直接對外部訪問，可以直接分配到業務IP，而且如果網絡設備支持BGP的話，可以用它實現大規模的容器網絡。但BGP帶給它的好處的同時也帶給他的劣勢，BGP協議在企業內部還很少被接受，企業網管不太願意在跨網絡的路由器上開啟BGP協議。

1.3 總結

跨主機的容器網絡解決方案不外乎三大類：

隧道方案：比如Flannel的 VxLan。特點是對底層的網絡沒有過高的要求，一般來說只要是三層可達就可以，只要是在一個三層可達網絡里，就能構建出一個基於隧道的容器網絡。問題也很明顯，一個大家共識是隨着節點規模的增長復雜度會提升，而且出了網絡問題跟蹤起來比較麻煩，大規模集群情況下這是需要考慮的一個點。
路由方案：路由技術從三層實現跨主機容器互通，沒有NAT，效率比較高，和目前的網絡能夠融合在一起，每一個容器都可以像虛擬機一樣分配一個業務的IP。但路由網絡也有問題，路由網絡對現有網絡設備影響比較大，路由器的路由表應該有空間限制一般是兩三萬條。而容器的大部分應用場景是運行微服務，數量集很大。如果幾萬新的容器IP沖擊到路由表里，導致下層的物理設備沒辦法承受；而且每一個容器都分配一個業務IP，業務IP消耗會很快。
VLAN：所有容器和物理機在同一個 VLAN 中。

1.4 一個網友的性能測試報告

來源：https://www.douban.com/note/530365327/

結論：

方案	結論	優勢	劣勢
weave(udp)	真是慘，生產環境就別考慮了。看了下他們的架構，覺得即便是 fast-data-path 也沒多大意義。	無	就是個渣渣，概念好毛用都沒
calico	calico 的 2 個方案都有不錯的表現，其中 ipip 的方案在 big msg size 上表現更好，但蹊蹺是在 128 字節的時候表現異常，多次測試如此。bgp 方案比較穩定，CPU 消耗並沒有 ipip 的大，當然帶寬表現也稍微差點。不過整體上來說，無論是 bgp 還是 ipip tunnel，calico 這套 overlay sdn 的解決方案成熟度和可用度都相當不錯，為雲上第一選擇。	性能衰減少，可控性高，隔離性棒	操作起來還是比較復雜，比如對 iptables 的依賴什么的
flannel	flannel 的 2 個方案表現也湊合，其中 vxlan 方案是因為沒法開 udp offload 導致性能偏低，其他的測試報告來看，一旦讓網卡自行解 udp 包拿到 mac 地址什么的，性能基本上可以達到無損，同時 cpu 占用率相當漂亮。udp 方案受限於 user space 的解包，僅僅比 weave(udp) 要好一點點。好的這一點就是在實現方面更加高效。	部署簡單，性能還行，可以兼容老版本 docker 的啟動分配行為，避免 launcher	沒法實現固定 IP 的容器漂移，沒法多子網隔離，對上層設計依賴度高，沒有 IPAM，對 docker 啟動方法有綁定
docker 原生 overlay 方案	其實也是基於 vxlan 實現的。受限於 cloud 上不一定會開的網卡 udp offload，vxlan 方案的性能上限就是裸機的 55% 左右了。大體表現上與 flannel vxlan 方案幾乎一致。	docker 原生，性能湊合	對內核要求高（>3.16），對 docker daemon 有依賴需求 ( consul / etcd )，本身驅動實現還是略差點，可以看到對 cpu 利用率和帶寬比同樣基於 vxlan 的 flannel 要差一些，雖然有 api 但對 network 以及多子網隔離局部交叉這種需求還是比較麻煩，IPAM 就是個渣

綜上，雲上能用 BGP 就果斷上 calico bgp 方案，不能用 BGP 也可以考慮 calico ipip tunnel 方案，如果是 coreos 系又能開 udp offload，flannel 是不錯的選擇。Docker overlay network 還有很長一段路要走，weave 就不用考慮了。

2. 若干企業生產環境中的容器網絡方案

2.1 PPTV Docker網絡解決方案 - 基於 linux bridge

（0）PPTV 容器雲架構

（1）網絡需求

網絡組人力不足以維護一個Overlay網絡，Overlay網絡出問題排查復雜，會出現失控的狀態。
隧道技術影響性能，不能滿足生產環境對網絡性能的要求。
開啟bgp對現有網絡改動太大，無法接受。
運維組同學希望能通過網絡橋接的方案解決容器網絡。

（2）選中的方案

最終 PPTV 選中基於docker的bridge模式，將默認的docker bridge網橋替換為 linuxbridge，把 linuxbridge 網段的 ip 加入到容器里，實現容器與傳統環境應用的互通。

首先會在該主機上添加一個linux bridge，把主機網卡，可以是物理機的，也可以是虛擬機的，把這個網卡加入bridge里面，bridge配上網卡原本的管理IP。
創建一個新的docker bridge網絡，指定bridge子網，並將該網絡的網橋綁定到上一步創建的網橋上。

docker network create --gateway10.199.45.200 --subnet 10.199.45.0/24 -o com.docker.network.bridge.name=br-oak--aux-address "DefaultGatewayIPv4=10.199.45.1" oak-net

容器啟動時候，指定容器網絡為第二步中創建的bridge網絡，同時為容器指定一個該網絡子網內的IP。容器啟動后網絡IP默認即可與外界互通。

（3）問題及解決方案

通過網橋的方式解決容器網絡有兩個問題:

容器跨主機漂移要求宿主機在同一個VLAN 中：linux bridge 只能添加跟 slavehost 同一個vlan的IP，也就是說容器IP必須要和宿主機在同一vlan下，這在一定程度上就限制了容器跨宿主機漂移的范圍。不過這個問題在PPTV 的生產環境中天然不存在，因為我們的生產環境中，每個數據中心的主機都在一個很大的子網內，基本能滿足容器在整個數據中心的任意節點下漂移。
跨主機的 IP 地址分配需要避免地址沖突：要讓容器 IP 在不同的宿主機上漂移，宿主機的 docker 網絡需要使用同一個CIDR，也就是各宿主機的容器使用同一個網段。而不同宿主機的使用同一個容器網段就會涉及到IPAM的問題，因為宿主機的docker daemon只知道他本機上的容器使用了哪些IP，而這些IP在其他宿主機上有沒有被使用，是不知道的。在默認的docker bridge中，因為這些ip不會直接與外部通信，所以容器使用相同IP也不會有問題，但是當容器網絡通過linux bridge打通以后，所有容器都是2層互通的，也就是會出現IP沖突的問題。為了解決上邊提到的問題，實現全局的IP管控，我們開發了IP池管理平台，實現對容器IP的分配管理。
需要更新服務自動注冊、自動發現：因為原先的方案是基於NAT的模式做的，而現在實現了獨立IP的功能。我們需要將現有的平台與PPTV內部的DNS做自動化對接，每當有容器創建和生成時，都會自動對容器的IP做DNS解析。
負載均衡：PPTV的負載均衡基本都是通過LVS + nginx實現的，但對於后台的容器應用來說，每次擴容和縮容、或者創建新的應用，負載均衡的后端配置也是需要自動更新的。

2.2 宜信的容器網絡解決方案 - 基於 Calico

（1）網絡需求

讓每個容器擁有自己的網絡棧，特別是獨立的 IP 地址
能夠進行跨服務器的容器間通訊，同時不依賴特定的網絡設備
有訪問控制機制，不同應用之間互相隔離，有調用關系的能夠通訊

（2）調研過程和最終的選擇

調研了幾個主流的網絡模型：

Docker 原生的 Bridge 模型：NAT 機制導致無法使用容器 IP 進行跨服務器通訊（后來發現自定義網橋可以解決通訊問題，但是覺得方案比較復雜）
Docker 原生的 Host 模型：大家都使用和服務器相同的 IP，端口沖突問題很麻煩
Weave OVS 等基於隧道的模型：由於是基於隧道的技術，在用戶態進行封包解包，性能折損比較大，同時出現問題時網絡抓包調試會很蛋疼
Project Calico 是純三層的 SDN 實現，它基於 BPG 協議和 Linux 自己的路由轉發機制，不依賴特殊硬件，沒有使用 NAT 或 Tunnel 等技術。能夠方便的部署在物理服務器，虛擬機（如 OpenStack）或者容器環境下。同時它自帶的基於 Iptables 的 ACL 管理組件非常靈活，能夠滿足比較復雜的安全隔離需求。

各種方案的限制：

Docker Bridge：每個容器里面都有一個虛擬網卡，和主機上的虛擬網卡做配合，所有容器內的虛擬網卡都可以和主機通信。通過端口映射，我調用對方的容器服務的時候，不能使用該容器直接的地址，必須使用它主機的地址。因為有了這樣一個轉發，網絡通訊的性能有所損耗。當然，還有一個問題更嚴重，訪問你的容器先要搞清楚你的主機是什么，這樣網絡通訊會跳來跳去。不但麻煩，還會帶來端口沖突。每創建一個容器會綁定一個端口，怎么管理好這些端口是一個很大的挑戰。
Fannel：這個方法有幾個問題，第一個是要做封包的操作，這會帶來網絡性能損失。第二個問題是每個主機上的容器是固定的，容器的不同主機之前的遷移必然帶來IP的變化。
Weave：它的思路是共享IP而非綁定。在傳輸層先找到目標地址，然后把包發到對端，節點之間互相通過協議共享信息。Flannel和Weave的特點是類似的，都用的是UDP或者是VxLAN的技術。事實上使用UDP性能是很差的，VxLAN和UDP差不多，它有一個網絡切隔，而且在里面可以跑二層協議。還有一種是IPIP封包，直接把一個IP包封裝在一個IP包里面。以上不難看出，原生網絡性能比較差，使用UDP的時候性能損失在50%以上，使用VxLAN也會有20%～30%的損耗。所以我要在內核上封包，使用硬件來解決這些問題。而且容器和容器之間出現通訊故障，調試的時候非常困難

（3）Calico 使用總結

Calico 的應用場景主要是IDC內部，推薦部署在二層網絡上，這樣所有路由器之間是互通的。這種場景是大二層的解決方案，所有服務器都在里面。但大二層主要的問題是彈性伸縮的問題。頻繁開關機的時候，容器啟停雖然不影響交換機，但容易產生廣播風暴。網絡規模太大的時候，一旦出現了這樣的問題，整個網絡都會有故障，這個問題還沒有解決的特別好。
Calico作為一個純二層的應用問題不大。我們可以把集群分成了很多網段，對外是三層網絡的結構。集群內部分成多個自制域，比如一個機櫃是一個自制域，之間通過交換路由的方式實現在三層容器到容器的互通。瓶頸在於容器的路由信息容量。所以說本質上它不是一個應對互聯網規模的解決方案，但對宜信場景是夠用的。
我們實施的時候遇到一些坑，比如容器在啟動時沒有網絡、操作ETCD的時候BGP配置頻繁加載，等等，最后我們多一一解決了。我們也發現了driver方案功能方面的弱點，現在還繼續使用劫持API的方法。如果要在雲上使用，如果支持BGP，直接可以用；如果不支持BGP可以用IPIP。現在英特爾的網卡支持兩個協議，一個是GRE、一個是VxLAN。如果真的把它放在雲上，我們可以考慮一下把VxLAN引進來，性能上的差別不是很大。