這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】Flannel是 CoreOS 團隊針對 Kubernetes 設計的一個覆蓋網路（Overlay Network）工具，其目的在於協助每一個使用 Kuberentes 的 CoreOS 主機擁有一個完整的子網。這次的分享內容將從Flannel的介紹、工作原理及安裝和配置三方面來介紹這個工具的使用方法。
第一部分：Flannel介紹
Flannel是CoreOS團隊針對Kubernetes設計的一個網路規劃服務，簡單來說，它的功能是讓叢集中的不同節點主機建立的Docker容器都具有全叢集唯一的虛擬IP地址。
在Kubernetes的網路模型中，假設了每個物理節點應該具備一段“屬於同一個內網IP段內”的“專用的子網IP”。例如：
節點A：10.0.1.0/24
節點B：10.0.2.0/24
節點C：10.0.3.0/24
但在預設的Docker配置中，每個節點上的Docker服務會分別負責所在節點容器的IP分配。這樣導致的一個問題是，不同節點上容器可能獲得相同的內外IP地址。並使這些容器之間能夠之間通過IP地址相互找到，也就是相互ping通。
Flannel的設計目的就是為叢集中的所有節點重新規劃IP地址的使用規則，從而使得不同節點上的容器能夠獲得“同屬一個內網”且”不重複的”IP地址，並讓屬於不同節點上的容器能夠直接通過內網IP通訊。
第二部分：Flannel的工作原理
Flannel實質上是一種“覆蓋網路(overlay network)”，也就是將TCP資料封裝在另一種網路包裡面進行路由轉寄和通訊，目前已經支援UDP、VxLAN、AWS VPC和GCE路由等資料轉寄方式。
預設的節點間資料通訊方式是UDP轉寄，在Flannel的GitHub頁面有如下的一張原理圖：
這張圖的資訊量很全，下面簡單的解讀一下。
資料從源容器中發出後，經由所在主機的docker0虛擬網卡轉寄到flannel0虛擬網卡，這是個P2P的虛擬網卡，flanneld服務監聽在網卡的另外一端。
Flannel通過Etcd服務維護了一張節點間的路由表，在稍後的配置部分我們會介紹其中的內容。
源主機的flanneld服務將原本的資料內容UDP封裝後根據自己的路由表投遞給目的節點的flanneld服務，資料到達以後被解包，然後直接進入目的節點的flannel0虛擬網卡，然後被轉寄到目的主機的docker0虛擬網卡，最後就像本機容器通訊一下的有docker0路由到達目標容器。
這樣整個資料包的傳遞就完成了，這裡需要解釋三個問題。
第一個問題，UDP封裝是怎麼一回事？
我們來看下面這個圖，這是在其中一個通訊節點上抓取到的ping命令通訊資料包。可以看到在UDP的資料內容部分其實是另一個ICMP（也就是ping命令）的資料包。
未經處理資料是在起始節點的Flannel服務上進行UDP封裝的，投遞到目的節點後就被另一端的Flannel服務還原成了原始的資料包，兩邊的Docker服務都感覺不到這個過程的存在。
第二個問題，為什麼每個節點上的Docker會使用不同的IP位址區段？
這個事情看起來很詭異，但真相十分簡單。其實只是單純的因為Flannel通過Etcd分配了每個節點可用的IP位址區段後，偷偷的修改了Docker的啟動參數，見。
這個是在運行了Flannel服務的節點上查看到的Docker服務進程運行參數。
注意其中的“--bip=172.17.18.1/24”這個參數，它限制了所在節點容器獲得的IP範圍。
這個IP範圍是由Flannel自動分配的，由Flannel通過儲存在Etcd服務中的記錄確保它們不會重複。
第三個問題，為什麼在發送節點上的資料會從docker0路由到flannel0虛擬網卡，在目的節點會從flannel0路由到docker0虛擬網卡？
我們來看一眼安裝了Flannel的節點上的路由表。下面是資料發送節點的路由表：
這個是資料接收節點的路由表：
例如現在有一個資料包要從IP為172.17.18.2的容器發到IP為172.17.46.2的容器。根據資料發送節點的路由表，它只與172.17.0.0/16匹配這條記錄匹配，因此資料從docker0出來以後就被投遞到了flannel0。同理在目標節點，由於投遞的地址是一個容器，因此目的地址一定會落在docker0對於的172.17.46.0/24這個記錄上，自然的被投遞到了docker0網卡。
第三部分：Flannel的安裝和配置
Flannel是Golang編寫的程式，因此的安裝十分簡單。
從https://github.com/coreos/flannel/releases和https://github.com/coreos/etcd/releases分別下載Flannel和Etcd的最新版本二進位包。
解壓後將Flannel的二進位檔案“flanneld”和指令檔“mk-docker-opts.sh”、以及Etcd的二進位檔案“etcd”和“etcdctl”放到系統的PATH目錄下面安裝就算完成了。
配置部分要複雜一些。
首先啟動Etcd，參考https://github.com/coreos/etcd ... overy。
訪問這個地址：https://discovery.etcd.io/new?size=3 獲得一個“Discovery地址”
在每個節點上運行以下啟動命令：
etcd -initial-advertise-peer-urls http://<當前節點IP>:2380 -listen-peer-urls http://<當前節點IP>:2380 -listen-client-urls http://<當前節點IP>:2379,http://<當前節點IP>:2379 -advertise-client-urls http://<當前節點IP>:2379 -discovery <剛剛獲得的Discovery地址> &
啟動完Etcd以後，就可以配置Flannel了。
Flannel的配置資訊全部在Etcd裡面記錄，往Etcd裡面寫入下面這個最簡單的配置，只指定Flannel能用來分配給每個Docker節點的擬IP位址區段：
etcdctl set /coreos.com/network/config '{ "Network": "172.17.0.0/16" }'
然後在每個節點分別啟動Flannel：
flanneld &
最後需要給Docker動一點手腳，修改它的啟動參數和docker0地址。
在每個節點上執行：
sudo mk-docker-opts.sh -i
source /run/flannel/subnet.env
sudo rm /var/run/docker.pid
sudo ifconfig docker0 ${FLANNEL_SUBNET}
重啟動一次Docker，這樣配置就完成了。
現在在兩個節點分別啟動一個Docker容器，它們之間已經通過IP地址直接相互ping通了。
到此，整個Flannel叢集也就正常運行了。
最後，前面反覆提到過Flannel有一個儲存在Etcd的路由表，可以在Etcd資料中找到這些路由記錄，如。
Q&A
問：資料從源容器中發出後，經由所在主機的docker0虛擬網卡轉寄到flannel0虛擬網卡，這種P2P實際生產中是否存在丟包，或者此機制有高可用保障嗎？
答：只是原生P2P網卡，沒有經過外部網路，應該還比較穩定。但我這裡沒有具體資料。
問：UDP資料封裝，轉寄的形式也是UDP嗎？我們一般知道UDP發送資料是無狀態的，可靠嗎？
答：轉寄的是UDP，高並發資料流時候也許會有問題，我這裡同樣沒有資料。
問：實際上，kubernates是淡化了容器ip，外圍使用者只需關注所調用的服務，並不關心具體的ip，這裡fannel將IP分開且唯一，這樣做有什麼好處？有實際應用的業務情境嗎？
答： IP唯一是Kubernetes能夠組網的條件之一，不把網路拉通後面的事情都不好整。
問：Flannel通過Etcd分配了每個節點可用的IP位址區段後，偷偷的修改了Docker的啟動參數：那麼如果增加節點，或刪除節點，這些位址區段（ETCD上）會動態變化嗎？如果不是動態變化，會造成IP地址的浪費嗎？
答會造成一些浪費，一般使用10.x.x.x的IP段。
問：sudo mk-docker-opts.sh -i 這個命令具體幹什麼了？非coreos上使用flannel有什麼不同？
答：產生了一個Docker啟動的環境變數檔案，裡面給Docker增加了啟動參數。
沒有什麼不同，只是CoreOS整合了Flannel，在CoreOS上面啟動Flannel只是一行命令：systemctl start flanneld。
問：容器IP都是固定的嗎？外網與物理主機能ping通，也能ping通所有Docker叢集的容器IP？
答：不是固定的，IP分配還是Docker在做，Flannel只是分配了子網。
問：Flannel的能否實現VPN？你們有沒有研究過？
答： 應該不能，它要求這些容器本來就在一個內網裡面。
問：Flannl是誰開發的？全是對k8s的二次開發嗎？
答： CoreOS公司，不是k8s的二次開發，獨立的開源項目，給k8s提供基礎網路環境。
問：Flannel支援非封包的純轉寄嗎？這樣效能就不會有損失了？
答：非封裝怎樣路由呢？發出來的TCP包本身並沒有在網路間路由的資訊，別忘了，兩個Flannel不是直連的，隔著普通的區域網路絡。
問： Flanel現在到哪個版本了，後續版本有什麼側重點？效能最佳化，還是功能擴充？
答：還沒到1.0，在GitHub上面有他們的發展計劃，效能是很大的一部分。
問： 就是在CoreOS中，客戶還需要安裝Flannel嗎？
答：不需要，在啟動的Cloudinit配置裡面給Etcd寫入Flannel配置，然後加上flanneld.service command: start 就可以了，啟動完直接可用，文檔串連我不找了，有這段配置，現成的。
問： 可不可以直接用命令指定每個主機的ip範圍，然後做gre隧道實現節點之間的通訊？這樣也可以實現不同主機上的容器ip不同且可以相互連信吧？
答：還不支援指定哪個節點用那段IP，不過貌似可以在Etcd手改。
問： Flannel只是負責通訊服務，那是不是還要安裝k8s？
答：是的，k8s是單獨的。
問：現在Docker的網路組件還有什麼可以選擇或者推薦的?
答：Overlay網路的常用就是Flannel和Weave，其他OVS之類的另說了。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年8月25日晚群分享內容整理。分享人
林帆，ThoughtWorks成都Cloud&DevOps諮詢師，目前主要研究內容是應用程式容器化和CoreOS系統相關領域。《CoreOS實踐指南》和《CoreOS那些事》系列文章作者。將在8月28日的容器技術大會上分享CoreOS的話題。DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
