在《Docker和Kubernetes的前世今生（下）》中我們介紹了作爲目前主流的容器編排系統，Kubernetes支持的功能和爲容器集羣業務帶來的便利。而爲了設計並保障編排系統運作，Kubernetes對容器集羣進行了這樣的要求：任何pods之間的通信都可以在不使用NAT的情況下進行，即設定集羣內所有容器都是連通的。但Docker容器通過Namespace隔離，無法直接相互通信，默認可以通過共用宿主機的Network Namespace的方式，憑藉宿主機的網絡棧進行通訊。這樣的方式也導致了一系列問題，比如徵用宿主機端口時使端口資源很快不足使得通信規模受限，以及容器與宿主機共享的網絡會暴露宿主機信息，致使網絡傳輸存在安全隱患。
爲什麼需要Overlay Network？
爲了不影響隔離性並實現容器間的網絡通信，Docker通過虛擬網橋“連接”容器，使容器得以像物理節點一樣經過“交換機”通訊。Docker在宿主機上創建名爲docker0的虛擬網橋，對於每一個創建的容器均創建一對虛擬網卡設備，其中一端在docker0，另一端映射到容器內的eth0，並對容器內網卡分配一個容器網絡IP。通過這一對虛擬網卡，容器就相當於“連接”到網橋上，虛擬網卡接在網橋上時只負責接受數據包，不再調用網絡協議棧進行處理，因此只具有類似端口的作用。當容器A要訪問容器B時，只需要廣播ARP協議，通過docker0轉發請求到對應”端口”，就實現了數據的轉發。
然而，雖然虛擬網橋解決了同一宿主機下的容器間通信問題，以及容器與外部世界之間的通信，但是跨節點的容器通信依然存在問題。集羣中每個節點的docker0都是獨立的，不同節點分配的容器IP之間存在衝突的可能，因此需要有一個具有全局視角的上層網絡以實現跨節點的容器網絡，這便是Overlay Network解決方案的由來。
Flannel容器集羣網絡方案的出現
Flannel是由CoreOS提出的跨主通信容器網絡解決方案，通過分配和管理全局唯一容器IP以及實現跨組網絡轉發的方式，構建基於Overlay Network的容器通信網絡。作爲最早出現的網絡編排方案，Flannel是最簡單的集羣編排方案之一，爲容器跨節點通信提供了多種網絡連接方式，後續很多插件的方案也是基於Flannel的方案進行擴展。Flannel的框架包含以下組件：每個節點上的代理服務flanneld，負責爲每個主機分配和管理子網；全局的網絡配f置存儲etcd（或K8S API）負責存儲主機和容器子網的映射關係；多種網絡轉發功能的後端實現。本文主要介紹三種最常見的模式：UDP、VXLAN和Host-gateway（以下簡稱host-gw）。
https://www.cnblogs.com/liuhongru/p/11168269.html
Flannel數據轉發模式之UDP
UDP是與Docker網橋模式最相似的實現模式。不同的是，UDP模式在虛擬網橋基礎上引入了TUN設備（flannel0）。TUN設備的特殊性在於它可以把數據包轉給創建它的用戶空間進程，從而實現內核到用戶空間的拷貝。在Flannel中，flannel0由flanneld進程創建，因此會把容器的數據包轉到flanneld，然後由flanneld封包轉給宿主機發向外部網絡。
UDP轉發的過程爲：Node1的container-1發起的IP包（目的地址爲Node2的container-2）通過容器網關發到docker0，宿主機根據本地路由表將該包轉到flannel0，接着發給flanneld。Flanneld根據目的容器容器子網與宿主機地址的關係（由etcd維護）獲得目的宿主機地址，然後進行UDP封包，轉給宿主機網卡通過物理網絡傳送到目標節點。在UDP數據包到達目標節點後，根據對稱過程進行解包，將數據傳遞給目標容器。
https://www.cnblogs.com/chenqionghe/p/11718365.html
UDP模式使用了Flannel自定義的一種包頭協議，實現三層網絡Overlay網絡處理跨主通信的問題。但是由於數據在內核和用戶態經過了多次拷貝：容器是用戶態，docker0和flannel0是內核態，flanneld是用戶態，最終又要通過內核將數據發到外部網絡，因此性能損耗較大，對於有數據傳輸有要求的在線業務並不適用。
https://blog.csdn.net/CSUXD/article/details/101082697
Flannel數據轉發模式之VXLAN
如果要進行性能優化，就需要減少用戶態與內核態之間的數據拷貝，這就是VXLAN模式解決的問題。VXLAN的核心在於在三層網絡的基礎上構建了二層網絡，使分佈在不同節點上的所有容器在這個虛擬二層網絡下自由通信。二層虛擬網絡通過VXLAN在宿主機上創建的VTEP設備（flannel.1）實現，flannel.1和flanneld一樣負責封包解包工作，不同的是flannel.1的封解包對象是二層數據幀，在內核中完成。
VXLAN的轉發過程爲：Node1的容器container-1發出的數據包經過docker0，路由給VTEP設備。每個在flannel網絡中的節點，都會由flanneld維護一張路由表，指明發往目標容器網段的包應該經過的VTEP設備IP地址。Node1的VTEP會獲得數據包應該發向Node2的VTEP設備的IP，並通過本地的ARP表知道目的VTEP設備的MAC地址，然後封裝在數據包頭部構成二層數據幀並再加上VXLAN頭，標識是由VTEP設備處理的數據幀。另外，flannel會維護轉發數據庫FDB，記錄目標VTEP的MAC地址應該發往的宿主機（也就是Node2），宿主機網卡將封裝爲外部網絡傳輸的包轉發到Node2。數據幀在Node2上解封后，宿主機會識別VXLAN頭部，直接在內核拆包，然後轉發到目標VTEP設備並轉到對應容器。
作爲Flannel中最被普遍採用的方案，VXLAN採用的是內置在Linux內核裏的標準協議，因此雖然封包結構比UDP模式複雜，但裝包和解包過程均在內核中完成，實際的傳輸速度要比UDP模式快許多。較快的傳輸速度和對底層網絡的可兼容性也使得VXLAN適用性較其他模式更高，成爲業務環境下的主流選擇。
Flannel數據轉發模式之Host-gw
除去上述兩種模式外，Flannel還提供了一種純三層網絡模式host-gw。顧名思義，host-gw是一種主機網關模式，每個主機會維護一張路由表，記錄發往某目標容器子網的數據包的下一跳IP地址（也就是子網所在宿主機的IP）。宿主機將下一跳目的主機的MAC地址作爲目的地址，通過二層網絡把包發往目的主機。目的主機收到後，會直接轉發給對應容器。所以host-gw模式下，數據包直接以容器IP包的形式在網絡中傳遞，每個宿主機就是通信鏈路中的網關。
https://www.cnblogs.com/chenqionghe/p/11718365.html
和其他兩種模式相比，host-gw模式少了額外的封包和拆包過程，效率與虛擬機直接的通信相差無幾。但是，該模式要求所有節點都在物理二層網絡中聯通，且每個主機都需要維護路由表，節點規模較大時有較大的維護壓力，因此不適用複雜網絡。
基於星環TCOS的Flannel性能測試
目前UDP模式由於其性能問題已基本被棄用，因此對於三層物理網絡首選VXLAN模式，而二層網絡VXLAN和host-gw均可選用。爲了測試VXLAN和host-gw在二層網絡下性能，我們在實驗子網內對兩種模式進行了性能對比，以便更好的根據場景選擇模式。我們從帶寬和轉發吞吐量兩個方面考察性能，選擇了IPerf和netperf兩種網絡性能測試工具。
根據上面兩張測試數據可以得出：1、在TCP數據接收窗口相同的情況下，host-gw平均傳輸速度更快，比VXLAN快約20%，實驗環境下最終趨於相近的速率；2、host-gw的平均吞吐量較VXLAN模式高出約5%。由此可見，對於小規模集羣、二層網絡下的通信，可以優先選擇host-gw；而大規模集羣、三層網絡下的通信更適合走VXLAN模式。
和市場上很多雲服務商一樣，星環TCOS雲操作系統的容器網絡方案也兼容了Flannel。TCOS默認使用VXLAN模式，以滿足複雜網絡場景如跨子網通信、異地數據中心互聯等，更加適合私有云部署的複雜場景。另外，TCOS也保留了host-gw模式，爲小規模企業的扁平化網絡提供通信方案，或者網絡拓撲較簡單的公有云環境下使用。
TCOS還對Flannel進行了二次開發，在自行維護了多網絡和網絡防火牆功能的同時，引入Flannel並不具備的Network Policy，以對Pod、Service和 NameSpace進行精細化的防火牆管理。在TCOS網絡方案下，不同租戶可以根據需要創建網絡，彼此之間互不影響，滿足了多租戶網絡管理隔離。
Flannel出現後網絡編排方案的發展
Flannel作爲最早的跨網絡通信解決方案，提供了自動化簡單的策略，可以滿足一般情況下的跨節點容器通信。市場上的雲服務商如CDK Global、Ranchor、Platform9等都選擇在支持其他方案的基礎上保留了Flannel，足以見其在容器網絡通信的適用性。作爲容器網絡解決方案的先驅者，Flannel和其他企業級開源解決方案如Calico、Weave等一同驅動了網絡方案發展。
然而，雖然Flannel是最早爲Kubernetes集羣設計的自動化網絡方案，但其功能並不完善，如不支持Kubernetes的Network Policy，對於有容器隔離需求的業務有着很大侷限性。基於Flannel存在的問題和缺陷，也衍生出一批支持Network Policy、具備負載均衡功能等改良集羣網絡方案。這些方案從某種意義上來說可以被看做是Fannel的改進版，爲Kubernetes的容器集羣網絡通信提供了更多的選擇，網絡編排方案開始進入百花爭鳴的時代。
往期原創文章 ：
TCOS – 業界首個支持生產級大數據業務的容器操作系統
TDC–帶來新一代大數據產品形態
行業觀察: 雲+大數據+AI推動企業數據業務演進TCOS 2.0 發佈 | 面向異構聯邦的容器操作系統Docker與Kubernetes的前世今生（上）Docker和Kubernetes的前世今生（下）DevOps與SRE在容器時代下的發展與變化
作者介紹：
本文轉載自大數據開放實驗室，已經過對方授權。大數據開放實驗室由星環信息科技（上海）有限公司運營，致力於大數據技術的研究和傳播。