Kubernetes網(wǎng)絡(luò)問(wèn)題的4種解決方案是什么

Kubernetes網(wǎng)絡(luò)問(wèn)題的4種解決方案是什么，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

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

一、Kubernetes + Flannel

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

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

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

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

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

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

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

下面說(shuō)說(shuō)幾個(gè)場(chǎng)景：

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

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

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

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

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

5. 集群外部訪問(wèn)Pod或Service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、Kubernetes集成Calico

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

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

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

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

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

第一種無(wú)HTTPS連接etcd方案，HTTP模式部署即沒(méi)有證書(shū)，直接連接etcd
第二種HTTPS連接etcd集群方案，加載etcd https證書(shū)模式，有點(diǎn)麻煩

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

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

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

Docker 1.9開(kāi)始支持Contiv Netplugin，Contiv帶來(lái)的方便是用戶可以根據(jù)實(shí)例IP直接進(jìn)行訪問(wèn)。

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

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

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

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

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

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

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

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

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

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

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

看完上述內(nèi)容，你們掌握Kubernetes網(wǎng)絡(luò)問(wèn)題的4種解決方案是什么的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！