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

時間 2019-11-11

標籤理解 docker 若干企業生產環境容器網絡方案欄目 Docker 简体版

原文原文鏈接

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

（1）Docker 安裝及基本用法linux

（2）Docker 鏡像nginx

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

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

（5）Docker 網絡api

（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引進來，性能上的差異不是很大。