由于在企業(yè)中部署私有云的場景會更普遍，所以在私有云中運行Kubernetes + Docker集群之前，就需要自己搭建符合Kubernetes要求的網(wǎng)絡(luò)環(huán)境。現(xiàn)在的開源世界里，有很多開源組件可以幫助我們打通Docker容器和容器之間的網(wǎng)絡(luò)，實現(xiàn)Kubernetes要求的網(wǎng)絡(luò)模型。當然每種方案都有自己適合的場景，我們要根據(jù)自己的實際需要進行選擇。

一、Kubernetes + Flannel

Kubernetes的網(wǎng)絡(luò)模型假定了所有Pod都在一個可以直接連通的扁平的網(wǎng)絡(luò)空間中，這在GCE（Google Compute Engine）里面是現(xiàn)成的網(wǎng)絡(luò)模型，Kubernetes假定這個網(wǎng)絡(luò)已經(jīng)存在。而在私有云里搭建Kubernetes集群，就不能假定這個網(wǎng)絡(luò)已經(jīng)存在了。我們需要自己實現(xiàn)這個網(wǎng)絡(luò)假設(shè)，將不同節(jié)點上的Docker容器之間的互相訪問先打通，然后運行Kubernetes。

Flannel是CoreOS團隊針對Kubernetes設(shè)計的一個網(wǎng)絡(luò)規(guī)劃服務(wù)，簡單來說，它的功能是讓集群中的不同節(jié)點主機創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址。而且它還能在這些IP地址之間建立一個覆蓋網(wǎng)絡(luò)（Overlay Network），通過這個覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動地傳遞到目標容器內(nèi)。

下面是一張它的網(wǎng)絡(luò)原理圖：

可以看到，Flannel首先創(chuàng)建了一個名為flannel0的網(wǎng)橋，而且這個網(wǎng)橋的一端連接docker0的網(wǎng)橋，另一端連接一個名為flanneld的服務(wù)進程。

Flanneld進程并不簡單，它首先上連etcd，利用etcd來管理可分配的IP地址段資源，同時監(jiān)控etcd中每個Pod的實際地址，并在內(nèi)存中建立了一個Pod節(jié)點路由表；然后下連docker0和物理網(wǎng)絡(luò)，使用內(nèi)存中的Pod節(jié)點路由表，將docker0發(fā)給它的數(shù)據(jù)包包裝起來，利用物理網(wǎng)絡(luò)的連接將數(shù)據(jù)包投遞到目標flanneld上，從而完成pod到pod之間的直接的地址通信。

Flannel之間的底層通信協(xié)議的可選余地有很多，比如UDP、VXlan、AWS VPC等等。只要能通到對端的Flannel就可以了。源Flannel封包，目標Flannel解包，最終docker0看到的就是原始的數(shù)據(jù)，非常透明，根本感覺不到中間Flannel的存在。

Flannel的安裝配置網(wǎng)上講的很多，在這里就不在贅述了。在這里注意一點，就是flannel使用etcd作為數(shù)據(jù)庫，所以需要預(yù)先安裝好etcd。

下面說說幾個場景：

同一Pod內(nèi)的網(wǎng)絡(luò)通信。在同一個Pod內(nèi)的容器共享同一個網(wǎng)絡(luò)命名空間，共享同一個Linux協(xié)議棧。所以對于網(wǎng)絡(luò)的各類操作，就和它們在同一臺機器上一樣，它們可以用localhost地址直接訪問彼此的端口。其實這和傳統(tǒng)的一組普通程序運行的環(huán)境是完全一樣的，傳統(tǒng)的程序不需要針對網(wǎng)絡(luò)做特別的修改就可以移植了。這樣做的結(jié)果是簡單、安全和高效，也能減少將已經(jīng)存在的程序從物理機或者虛擬機移植到容器下運行的難度。

Pod1到Pod2的網(wǎng)絡(luò)，分兩種情況。Pod1與Pod2不在同一臺主機與Pod1與Pod2在同一臺主機。

先說Pod1與Pod2不在同一臺主機。Pod的地址是與docker0在同一個網(wǎng)段的，但docker0網(wǎng)段與宿主機網(wǎng)卡是兩個完全不同的IP網(wǎng)段，并且不同Node之間的通信只能通過宿主機的物理網(wǎng)卡進行。將Pod的IP和所在Node的IP關(guān)聯(lián)起來，通過這個關(guān)聯(lián)讓Pod可以互相訪問。
Pod1與Pod2在同一臺主機。Pod1和Pod2在同一臺主機的話，由Docker0網(wǎng)橋直接轉(zhuǎn)發(fā)請求到Pod2，不需要經(jīng)過Flannel。

Pod到Service的網(wǎng)絡(luò)。創(chuàng)建一個Service時，相應(yīng)會創(chuàng)建一個指向這個Service的域名，域名規(guī)則為{服務(wù)名}.{namespace}.svc.{集群名稱}。之前Service IP的轉(zhuǎn)發(fā)由iptables和kube-proxy負責，目前基于性能考慮，全部為iptables維護和轉(zhuǎn)發(fā)。iptables則由kubelet維護。Service僅支持UDP和TCP協(xié)議，所以像ping的ICMP協(xié)議是用不了的，所以無法ping通Service IP。

Pod到外網(wǎng)。Pod向外網(wǎng)發(fā)送請求，查找路由表, 轉(zhuǎn)發(fā)數(shù)據(jù)包到宿主機的網(wǎng)卡，宿主網(wǎng)卡完成路由選擇后，iptables執(zhí)行Masquerade，把源IP更改為宿主網(wǎng)卡的IP，然后向外網(wǎng)服務(wù)器發(fā)送請求。

集群外部訪問Pod或Service

由于Pod和Service是Kubernetes集群范圍內(nèi)的虛擬概念，所以集群外的客戶端系統(tǒng)無法通過Pod的IP地址或者Service的虛擬IP地址和虛擬端口號訪問到它們。為了讓外部客戶端可以訪問這些服務(wù)，可以將Pod或Service的端口號映射到宿主機，以使得客戶端應(yīng)用能夠通過物理機訪問容器應(yīng)用。

總結(jié)：Flannel實現(xiàn)了對Kubernetes網(wǎng)絡(luò)的支持，但是它引入了多個網(wǎng)絡(luò)組件，在網(wǎng)絡(luò)通信時需要轉(zhuǎn)到flannel0網(wǎng)絡(luò)接口，再轉(zhuǎn)到用戶態(tài)的flanneld程序，到對端后還需要走這個過程的反過程，所以也會引入一些網(wǎng)絡(luò)的時延損耗。另外Flannel默認的底層通信協(xié)議是UDP。UDP本身是非可靠協(xié)議，雖然兩端的TCP實現(xiàn)了可靠傳輸，但在大流量、高并發(fā)應(yīng)用場景下還需要反復(fù)調(diào)試，確保不會出現(xiàn)傳輸質(zhì)量的問題。特別是對網(wǎng)絡(luò)依賴重的應(yīng)用，需要評估對業(yè)務(wù)的影響。

二、基于Docker Libnetwork的網(wǎng)絡(luò)定制

容器跨主機的網(wǎng)絡(luò)通信，主要實現(xiàn)思路有兩種：二層VLAN網(wǎng)絡(luò)和Overlay網(wǎng)絡(luò)。

二層VLAN網(wǎng)絡(luò)的解決跨主機通信的思路是把原先的網(wǎng)絡(luò)架構(gòu)改造為互通的大二層網(wǎng)絡(luò)，通過特定網(wǎng)絡(luò)設(shè)備直接路由，實現(xiàn)容器點到點的之間通信。 Overlay網(wǎng)絡(luò)是指在不改變現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施的前提下，通過某種約定通信協(xié)議，把二層報文封裝在IP報文之上的新的數(shù)據(jù)格式。

Libnetwork是Docker團隊將Docker的網(wǎng)絡(luò)功能從Docker核心代碼中分離出去，形成一個單獨的庫。 Libnetwork通過插件的形式為Docker提供網(wǎng)絡(luò)功能。 使得用戶可以根據(jù)自己的需求實現(xiàn)自己的Driver來提供不同的網(wǎng)絡(luò)功能。

Libnetwork所要實現(xiàn)的網(wǎng)絡(luò)模型基本是這樣的： 用戶可以創(chuàng)建一個或多個網(wǎng)絡(luò)（一個網(wǎng)絡(luò)就是一個網(wǎng)橋或者一個VLAN ），一個容器可以加入一個或多個網(wǎng)絡(luò)。 同一個網(wǎng)絡(luò)中容器可以通信，不同網(wǎng)絡(luò)中的容器隔離。這才是將網(wǎng)絡(luò)從docker分離出去的真正含義，即在創(chuàng)建容器之前，我們可以先創(chuàng)建網(wǎng)絡(luò)（即創(chuàng)建容器與創(chuàng)建網(wǎng)絡(luò)是分開的），然后決定讓容器加入哪個網(wǎng)絡(luò)。

Libnetwork實現(xiàn)了5種網(wǎng)絡(luò)模式：

1、 bridge：Docker默認的容器網(wǎng)絡(luò)驅(qū)動，Container通過一對veth pair鏈接到docker0網(wǎng)橋上，由Docker為容器動態(tài)分配IP及配置路由、防火墻等。
2、host：容器與主機共享同一Network Namespace。
3、 null：容器內(nèi)網(wǎng)絡(luò)配置為空，需要用戶手動為容器配置網(wǎng)絡(luò)接口及路由。
4、 remote：Docker網(wǎng)絡(luò)插件的實現(xiàn)，Remote driver使得Libnetwork可以通過HTTP Resful API 對接第三方的網(wǎng)絡(luò)方案，類似于SocketPlane的SDN方案只要實現(xiàn)了約定的HTTP URL處理函數(shù)以及底層的網(wǎng)絡(luò)接口配置方法，就可以替代Docker原生的網(wǎng)絡(luò)實現(xiàn)。
5、 overlay：Docker原生的跨主機多子網(wǎng)網(wǎng)絡(luò)方案。

Docker自身的網(wǎng)絡(luò)功能比較簡單，不能滿足很多復(fù)雜的應(yīng)用場景。因此，有很多開源項目用來改善Docker的網(wǎng)絡(luò)功能，如Pipework、Weave、SocketPlane等。

舉例：網(wǎng)絡(luò)配置工具Pipework

Pipework是一個簡單易用的Docker容器網(wǎng)絡(luò)配置工具。由200多行shell腳本實現(xiàn)。通過使用IP、brctl、ovs-vsctl等命令來為Docker容器配置自定義的網(wǎng)橋、網(wǎng)卡、路由等。有如下功能：

支持使用自定義的Linux Bridge、veth pair為容器提供通信。 支持使用MacVLAN設(shè)備將容器連接到本地網(wǎng)絡(luò)。 支持DHCP獲取容器的IP。 支持Open vSwitch。 支持VLAN劃分。

Pipework簡化了在復(fù)雜場景下對容器連接的操作命令，為我們配置復(fù)雜的網(wǎng)絡(luò)拓撲提供了一個強有力的工具。對于一個基本應(yīng)用而言，Docker的網(wǎng)絡(luò)模型已經(jīng)很不錯了。然而，隨著云計算和微服務(wù)的興起，我們不能永遠停留在使用基本應(yīng)用的級別上，我們需要性能更好且更靈活的網(wǎng)絡(luò)功能。Pipework是個很好的網(wǎng)絡(luò)配置工具，但Pipework并不是一套解決方案，我們可以利用它提供的強大功能，根據(jù)自己的需求添加額外的功能，幫助我們構(gòu)建自己的解決方案。

OVS跨主機多子網(wǎng)網(wǎng)絡(luò)方案

OVS的優(yōu)勢是，作為開源虛擬交換機軟件，它相對成熟和穩(wěn)定，而且支持各類網(wǎng)絡(luò)隧道協(xié)議，經(jīng)過了OpenStack等項目的考驗。這個網(wǎng)上很多，就不再贅述了。

三、Kubernetes集成Calico

Calico是一個純3層的數(shù)據(jù)中心網(wǎng)絡(luò)方案，而且無縫集成像OpenStack這種IaaS云架構(gòu)，能夠提供可控的VM、容器、裸機之間的IP通信。

通過將整個互聯(lián)網(wǎng)的可擴展IP網(wǎng)絡(luò)原則壓縮到數(shù)據(jù)中心級別，Calico在每一個計算節(jié)點利用Linux Kernel實現(xiàn)了一個高效的vRouter來負責數(shù)據(jù)轉(zhuǎn)發(fā)，而每個vRouter通過BGP協(xié)議負責把自己上運行的workload的路由信息像整個Calico網(wǎng)絡(luò)內(nèi)傳播——小規(guī)模部署可以直接互聯(lián)，大規(guī)模下可通過指定的BGP route reflector來完成。這樣保證最終所有的workload之間的數(shù)據(jù)流量都是通過IP路由的方式完成互聯(lián)的。

Calico節(jié)點組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（無論是L2或者L3），不需要額外的NAT，隧道或者Overlay Network。

Calico基于iptables還提供了豐富而靈活的網(wǎng)絡(luò)Policy，保證通過各個節(jié)點上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達性限制等功能。

Calico有兩種布署方案，一般集群都配有SSL證書和非證書的情況。

第一種無HTTPS連接etcd方案，HTTP模式部署即沒有證書，直接連接etcd 第二種HTTPS連接etcd集群方案，加載etcd https證書模式，有點麻煩

總結(jié)：目前Kubernetes網(wǎng)絡(luò)最快的第一就是Calico，第二種稍慢Flannel，根據(jù)自己的網(wǎng)絡(luò)環(huán)境條件來定。
calico與flannel的對比：
下圖是從網(wǎng)上找到的各個開源網(wǎng)絡(luò)組件的性能對比，可以看出無論是帶寬還是網(wǎng)絡(luò)延遲，calico和主機的性能是差不多的，calico是明顯優(yōu)于flannel的。

Calico作為一款針對企業(yè)級數(shù)據(jù)中心的虛擬網(wǎng)絡(luò)工具，借助BGP、路由表和iptables，實現(xiàn)了一個無需解包封包的三層網(wǎng)絡(luò)，并且有調(diào)試簡單的特點。雖然目前還有些小缺陷，比如stable版本還無法支持私有網(wǎng)絡(luò)，但希望在后面的版本中改進并會更加強大。

四、應(yīng)用容器IP固定（參考網(wǎng)上資料）

Docker 1.9開始支持Contiv Netplugin，Contiv帶來的方便是用戶可以根據(jù)實例IP直接進行訪問。

Docker 1.10版本支持指定IP啟動容器，并且由于部分數(shù)據(jù)庫應(yīng)用對實例IP固定有需求，有必要研究容器IP固定方案的設(shè)計。

在默認的Kubernetes + Contiv的網(wǎng)絡(luò)環(huán)境下，容器Pod的IP網(wǎng)絡(luò)連接是由Contiv Network Plugin來完成的，Contiv Master只實現(xiàn)了簡單的IP地址分配和回收，每次部署應(yīng)用時，并不能保證Pod IP不變。所以可以考慮引入新的Pod層面的IPAM（IP地址管理插件），以保證同一個應(yīng)用多次發(fā)生部署時，Pod IP始終是不變的。

作為Pod層面的IPAM，可以把這一功能直接集成在Kubernetes里。Pod作為Kubernetes的最小調(diào)度單元，原有的Kubernetes Pod Registry（主要負責處理所有與Pod以及Pod subresource相關(guān)的請求：Pod的增刪改查，Pod的綁定及狀態(tài)更新，exec/attach/log等操作）并不支持在創(chuàng)建Pod時為Pod分配IP，Pod IP是通過獲取Pod Infra Container的IP來獲取的，而Pod Infra Container的IP即為Contiv動態(tài)分配得來的。

在原有Kubernetes代碼基礎(chǔ)上，修改Pod結(jié)構(gòu)（在PodSpec中加入PodIP）并重寫了Pod Registry同時引入了兩個新的資源對象：

Pod IP Allocator：Pod IP Allocator是一個基于etcd的IP地址分配器，主要實現(xiàn)Pod IP的分配與回收。Pod IP Allocator通過位圖記錄IP地址的分配情況，并且將該位圖持久化到etcd； Pod IP Recycler：Pod IP Recycler是一個基于etcd的IP地址回收站，也是實現(xiàn)PodConsistent IP的核心。Pod IP Recycler基于RC全名（namespace + RC name）記錄每一個應(yīng)用曾經(jīng)使用過的IP地址，并且在下一次部署的時候預(yù)先使用處于回收狀態(tài)的IP。Pod IP Recycler只會回收通過RC創(chuàng)建的Pod的IP，通過其他controller或者直接創(chuàng)建的Pod的IP并不會記錄，所以通過這種方式創(chuàng)建的Pod的IP并不會保持不變；同時Pod IP Recycle檢測每個已回收IP對象的TTL，目前設(shè)置的保留時間為一天。

這里對kubelet也需要進行改造，主要包括根據(jù)Pod Spec中指定IP進行相關(guān)的容器創(chuàng)建（docker run加入IP指定）以及Pod刪除時釋放IP操作。

Pod的創(chuàng)建在PaaS里主要有兩種情形：

應(yīng)用的第一次部署及擴容，這種情況主要是從IP pool中隨機分配； 應(yīng)用的重新部署：在重新部署時，已經(jīng)釋放的IP已根據(jù)RC全名存放于IP Recycle列表中，這里優(yōu)先從回收列表中獲取IP，從而達到IP固定的效果。

另外為了防止IP固定方案中可能出現(xiàn)的問題，在Kubernetes中加入了額外的REST API：包括對已分配IP的查詢，手動分配/釋放IP。

容器IP固定方案已測試評估中，運行基本上沒問題，但穩(wěn)定性有待提升。主要表現(xiàn)在有時不能在預(yù)期時間內(nèi)停止舊Pod，從而無法釋放IP造成無法復(fù)用（初步原因是由于Docker偶爾的卡頓造成無法在規(guī)定時間內(nèi)停止容器），可以手動去修復(fù)。但從長期考慮，IP固定方案還需要加強穩(wěn)定性并根據(jù)具體需求進行優(yōu)化。

總結(jié)：目前已有多種支持Kubernetes的網(wǎng)絡(luò)方案，比如Flannel、Calico、華為的Canal、Weave Net等。因為它們都實現(xiàn)了CNI規(guī)范，用戶無論選擇哪種方案，得到的網(wǎng)絡(luò)模型都一樣，即每個Pod都有獨立的 IP，可以直接通信。區(qū)別在于不同方案的底層實現(xiàn)不同，有的采用基于VXLAN的Overlay實現(xiàn)，有的則是Underlay，性能上有區(qū)別，再有就是是否支持Network Policy了。

總結(jié)

以上是生活随笔為你收集整理的盘点Kubernetes网络问题的4种解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。