Kubernetes研究：網(wǎng)絡(luò)原理及方案（網(wǎng)絡(luò)原理基礎(chǔ)經(jīng)典版）

作者：大數(shù)據(jù)技術(shù)實(shí)戰(zhàn) 2019-10-24 11:10:06

云計(jì)算 說到容器、Docker，大家一定會想到Kubernetes，確實(shí)如此，在2016年ClusterHQ容器技術(shù)應(yīng)用調(diào)查報(bào)告顯示，Kubernetes的使用率已經(jīng)達(dá)到了40%，成為容器編排工具；那么Kubernetes到底是什么呢?

成都網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、微信小程序開發(fā)、集團(tuán)成都企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。核心團(tuán)隊(duì)均擁有互聯(lián)網(wǎng)行業(yè)多年經(jīng)驗(yàn)，服務(wù)眾多知名企業(yè)客戶；涵蓋的客戶類型包括：成都鑿毛機(jī)等眾多領(lǐng)域，積累了大量豐富的經(jīng)驗(yàn)，同時(shí)也獲得了客戶的一致認(rèn)可！

 說到容器、Docker，大家一定會想到Kubernetes，確實(shí)如此，在2016年ClusterHQ容器技術(shù)應(yīng)用調(diào)查報(bào)告顯示，Kubernetes的使用率已經(jīng)達(dá)到了40%，成為容器編排工具;那么Kubernetes到底是什么呢?它是一個(gè)用于容器集群的自動化部署、擴(kuò)容以及運(yùn)維的開源平臺;那么通過Kubernetes能干什么呢?它能快速而有預(yù)期地部署你的應(yīng)用，極速地?cái)U(kuò)展你的應(yīng)用，無縫對接新的應(yīng)用功能，節(jié)省資源，優(yōu)化硬件資源的使用。

隨著Kubernetes王者時(shí)代的到來，計(jì)算、網(wǎng)絡(luò)、存儲、安全是Kubernetes繞不開的話題，本次主要分享Kubernetes網(wǎng)絡(luò)原理及方案，后續(xù)還會有Kubernetes其它方面的分享，另外有容云5.22發(fā)布了基于Kubernetes的容器云平臺產(chǎn)品UFleet，想要獲取新品試用，歡迎聯(lián)系有容云。

一、Kubernetes網(wǎng)絡(luò)模型

在Kubernetes網(wǎng)絡(luò)中存在兩種IP(Pod IP和Service Cluster IP)，Pod IP 地址是實(shí)際存在于某個(gè)網(wǎng)卡(可以是虛擬設(shè)備)上的，Service Cluster IP它是一個(gè)虛擬IP，是由kube-proxy使用Iptables規(guī)則重新定向到其本地端口，再均衡到后端Pod的。下面講講Kubernetes Pod網(wǎng)絡(luò)設(shè)計(jì)模型：

1、基本原則：

每個(gè)Pod都擁有一個(gè)獨(dú)立的IP地址(IPper Pod)，而且假定所有的pod都在一個(gè)可以直接連通的、扁平的網(wǎng)絡(luò)空間中。

2、設(shè)計(jì)原因：

用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮將容器端口映射到主機(jī)端口等問題。

3、網(wǎng)絡(luò)要求：

所有的容器都可以在不用NAT的方式下同別的容器通訊;所有節(jié)點(diǎn)都可在不用NAT的方式下同所有容器通訊;容器的地址和別人看到的地址是同一個(gè)地址。

二、Docker網(wǎng)絡(luò)基礎(chǔ)

Linux網(wǎng)絡(luò)名詞解釋：

1、網(wǎng)絡(luò)的命名空間：Linux在網(wǎng)絡(luò)棧中引入網(wǎng)絡(luò)命名空間，將獨(dú)立的網(wǎng)絡(luò)協(xié)議棧隔離到不同的命令空間中，彼此間無法通信;docker利用這一特性，實(shí)現(xiàn)不容器間的網(wǎng)絡(luò)隔離。

2、Veth設(shè)備對：Veth設(shè)備對的引入是為了實(shí)現(xiàn)在不同網(wǎng)絡(luò)命名空間的通信。

3、Iptables/Netfilter：Netfilter負(fù)責(zé)在內(nèi)核中執(zhí)行各種掛接的規(guī)則(過濾、修改、丟棄等)，運(yùn)行在內(nèi)核 模式中;Iptables模式是在用戶模式下運(yùn)行的進(jìn)程，負(fù)責(zé)協(xié)助維護(hù)內(nèi)核中Netfilter的各種規(guī)則表;通過二者的配合來實(shí)現(xiàn)整個(gè)Linux網(wǎng)絡(luò)協(xié)議棧中靈活的數(shù)據(jù)包處理機(jī)制。

4、網(wǎng)橋：網(wǎng)橋是一個(gè)二層網(wǎng)絡(luò)設(shè)備,通過網(wǎng)橋可以將linux支持的不同的端口連接起來,并實(shí)現(xiàn)類似交換機(jī)那樣的多對多的通信。

5、路由：Linux系統(tǒng)包含一個(gè)完整的路由功能，當(dāng)IP層在處理數(shù)據(jù)發(fā)送或轉(zhuǎn)發(fā)的時(shí)候，會使用路由表來決定發(fā)往哪里。

• Docker生態(tài)技術(shù)棧

下圖展示了Docker網(wǎng)絡(luò)在整個(gè)Docker生態(tài)技術(shù)棧中的位置：

• Docker網(wǎng)絡(luò)實(shí)現(xiàn)

1、單機(jī)網(wǎng)絡(luò)模式：Bridge 、Host、Container、None，這里具體就不贅述了。

2、多機(jī)網(wǎng)絡(luò)模式：一類是 Docker 在 1.9 版本中引入Libnetwork項(xiàng)目，對跨節(jié)點(diǎn)網(wǎng)絡(luò)的原生支持;一類是通過插件(plugin)方式引入的第三方實(shí)現(xiàn)方案，比如 Flannel，Calico 等等。

三、Kubernetes網(wǎng)絡(luò)基礎(chǔ)

1、容器間通信：

同一個(gè)Pod的容器共享同一個(gè)網(wǎng)絡(luò)命名空間，它們之間的訪問可以用localhost地址 + 容器端口就可以訪問。

2、同一Node中Pod間通信：

同一Node中Pod的默認(rèn)路由都是docker0的地址，由于它們關(guān)聯(lián)在同一個(gè)docker0網(wǎng)橋上，地址網(wǎng)段相同，所有它們之間應(yīng)當(dāng)是能直接通信的。

3、不同Node中Pod間通信：

不同Node中Pod間通信要滿足2個(gè)條件： Pod的IP不能沖突; 將Pod的IP和所在的Node的IP關(guān)聯(lián)起來，通過這個(gè)關(guān)聯(lián)讓Pod可以互相訪問。

4、Service介紹：

Service是一組Pod的服務(wù)抽象，相當(dāng)于一組Pod的LB，負(fù)責(zé)將請求分發(fā)給對應(yīng)的

Pod;Service會為這個(gè)LB提供一個(gè)IP，一般稱為ClusterIP。

5、Kube-proxy介紹：

Kube-proxy是一個(gè)簡單的網(wǎng)絡(luò)代理和負(fù)載均衡器，它的作用主要是負(fù)責(zé)Service的實(shí)現(xiàn)，具體來說，就是實(shí)現(xiàn)了內(nèi)部從Pod到Service和外部的從NodePort向Service的訪問。

實(shí)現(xiàn)方式：

• userspace是在用戶空間，通過kuber-proxy實(shí)現(xiàn)LB的代理服務(wù)，這個(gè)是kube-proxy的最初的版本，較為穩(wěn)定，但是效率也自然不太高。
• iptables是純采用iptables來實(shí)現(xiàn)LB，是目前kube-proxy默認(rèn)的方式。

下面是iptables模式下Kube-proxy的實(shí)現(xiàn)方式：

在這種模式下，kube-proxy監(jiān)視Kubernetes主服務(wù)器添加和刪除服務(wù)和端點(diǎn)對象。對于每個(gè)服務(wù)，它安裝iptables規(guī)則，捕獲到服務(wù)的clusterIP(虛擬)和端口的流量，并將流量重定向到服務(wù)的后端集合之一。對于每個(gè)Endpoints對象，它安裝選擇后端Pod的iptables規(guī)則。

默認(rèn)情況下，后端的選擇是隨機(jī)的?？梢酝ㄟ^將service.spec.sessionAffinity設(shè)置為“ClientIP”(默認(rèn)為“無”)來選擇基于客戶端IP的會話關(guān)聯(lián)。

與用戶空間代理一樣，最終結(jié)果是綁定到服務(wù)的IP:端口的任何流量被代理到適當(dāng)?shù)暮蠖?，而客戶端不知道關(guān)于Kubernetes或服務(wù)或Pod的任何信息。這應(yīng)該比用戶空間代理更快，更可靠。然而，與用戶空間代理不同，如果最初選擇的Pod不響應(yīng)，則iptables代理不能自動重試另一個(gè)Pod，因此它取決于具有工作準(zhǔn)備就緒探測。

6、Kube-dns介紹

Kube-dns用來為kubernetes service分配子域名，在集群中可以通過名稱訪問service;通常kube-dns會為service賦予一個(gè)名為“service名稱.namespace.svc.cluster.local”的A記錄，用來解析service的clusterip。

Kube-dns組件：

• 在Kubernetes v1.4版本之前由“Kube2sky、Etcd、Skydns、Exechealthz”四個(gè)組件組成。
• 在Kubernetes v1.4版本及之后由“Kubedns、dnsmasq、exechealthz”三個(gè)組件組成。 

Kubedns

• 接入SkyDNS，為dnsmasq提供查詢服務(wù)。
• 替換etcd容器，使用樹形結(jié)構(gòu)在內(nèi)存中保存DNS記錄。
• 通過K8S API監(jiān)視Service資源變化并更新DNS記錄。
• 服務(wù)10053端口。

Dnsmasq

• Dnsmasq是一款小巧的DNS配置工具。
• 在kube-dns插件中的作用是：

1. 通過kubedns容器獲取DNS規(guī)則，在集群中提供DNS查詢服務(wù)
2. 提供DNS緩存，提高查詢性能
3. 降低kubedns容器的壓力、提高穩(wěn)定性

• Dockerfile在GitHub上Kubernetes組織的contrib倉庫中，位于dnsmasq目錄下。
• 在kube-dns插件的編排文件中可以看到，dnsmasq通過參數(shù)–server=127.0.0.1:10053指定upstream為kubedns。

Exechealthz

• 在kube-dns插件中提供健康檢查功能。
• 源碼同樣在contrib倉庫中，位于exec-healthz目錄下。
• 新版中會對兩個(gè)容器都進(jìn)行健康檢查，更加完善。

四、Kubernetes網(wǎng)絡(luò)開源組件

1、技術(shù)術(shù)語：

IPAM：IP地址管理;這個(gè)IP地址管理并不是容器所特有的，傳統(tǒng)的網(wǎng)絡(luò)比如說DHCP其實(shí)也是一種IPAM，到了容器時(shí)代我們談IPAM，主流的兩種方法： 基于CIDR的IP地址段分配地或者精確為每一個(gè)容器分配IP。但總之一旦形成一個(gè)容器主機(jī)集群之后，上面的容器都要給它分配一個(gè)全局唯一的IP地址，這就涉及到IPAM的話題。

Overlay：在現(xiàn)有二層或三層網(wǎng)絡(luò)之上再構(gòu)建起來一個(gè)獨(dú)立的網(wǎng)絡(luò)，這個(gè)網(wǎng)絡(luò)通常會有自己獨(dú)立的IP地址空間、交換或者路由的實(shí)現(xiàn)。

IPSesc：一個(gè)點(diǎn)對點(diǎn)的一個(gè)加密通信協(xié)議，一般會用到Overlay網(wǎng)絡(luò)的數(shù)據(jù)通道里。

vxLAN：由VMware、Cisco、RedHat等聯(lián)合提出的這么一個(gè)解決方案，這個(gè)解決方案最主要是解決VLAN支持虛擬網(wǎng)絡(luò)數(shù)量(4096)過少的問題。因?yàn)樵诠性粕厦恳粋€(gè)租戶都有不同的VPC，4096明顯不夠用。就有了vxLAN，它可以支持1600萬個(gè)虛擬網(wǎng)絡(luò)，基本上公有云是夠用的。

網(wǎng)橋Bridge： 連接兩個(gè)對等網(wǎng)絡(luò)之間的網(wǎng)絡(luò)設(shè)備，但在今天的語境里指的是Linux Bridge，就是大名鼎鼎的Docker0這個(gè)網(wǎng)橋。

BGP： 主干網(wǎng)自治網(wǎng)絡(luò)的路由協(xié)議，今天有了互聯(lián)網(wǎng)，互聯(lián)網(wǎng)由很多小的自治網(wǎng)絡(luò)構(gòu)成的，自治網(wǎng)絡(luò)之間的三層路由是由BGP實(shí)現(xiàn)的。

SDN、Openflow： 軟件定義網(wǎng)絡(luò)里面的一個(gè)術(shù)語，比如說我們經(jīng)常聽到的流表、控制平面，或者轉(zhuǎn)發(fā)平面都是Openflow里的術(shù)語。

2、容器網(wǎng)絡(luò)方案：

隧道方案( Overlay Networking )

隧道方案在IaaS層的網(wǎng)絡(luò)中應(yīng)用也比較多，大家共識是隨著節(jié)點(diǎn)規(guī)模的增長復(fù)雜度會提升，而且出了網(wǎng)絡(luò)問題跟蹤起來比較麻煩，大規(guī)模集群情況下這是需要考慮的一個(gè)點(diǎn)。

• Weave：UDP廣播，本機(jī)建立新的BR，通過PCAP互通
• Open vSwitch(OVS)：基于VxLan和GRE協(xié)議，但是性能方面損失比較嚴(yán)重
• Flannel：UDP廣播，VxLan
• Racher：IPsec

路由方案

路由方案一般是從3層或者2層實(shí)現(xiàn)隔離和跨主機(jī)容器互通的，出了問題也很容易排查。

Calico：基于BGP協(xié)議的路由方案，支持很細(xì)致的ACL控制，對混合云親和度比較高。

Macvlan：從邏輯和Kernel層來看隔離性和性能最優(yōu)的方案，基于二層隔離，所以需要二層路由器支持，大多數(shù)云服務(wù)商不支持，所以混合云上比較難以實(shí)現(xiàn)。

3、CNM & CNI陣營：

容器網(wǎng)絡(luò)發(fā)展到現(xiàn)在，形成了兩大陣營，就是Docker的CNM和Google、CoreOS、Kuberenetes主導(dǎo)的CNI。首先明確一點(diǎn)，CNM和CNI并不是網(wǎng)絡(luò)實(shí)現(xiàn)，他們是網(wǎng)絡(luò)規(guī)范和網(wǎng)絡(luò)體系，從研發(fā)的角度他們就是一堆接口，你底層是用Flannel也好、用Calico也好，他們并不關(guān)心，CNM和CNI關(guān)心的是網(wǎng)絡(luò)管理的問題。

CNM(Docker LibnetworkContainer Network Model):

Docker Libnetwork的優(yōu)勢就是原生，而且和Docker容器生命周期結(jié)合緊密;缺點(diǎn)也可以理解為是原生，被Docker“綁架”。

• Docker Swarm overlay
• Macvlan & IP networkdrivers
• Calico
• Contiv
• Weave

CNI(Container NetworkInterface)：

CNI的優(yōu)勢是兼容其他容器技術(shù)(e.g. rkt)及上層編排系統(tǒng)(Kubernetes & Mesos)，而且社區(qū)活躍勢頭迅猛，Kubernetes加上CoreOS主推;缺點(diǎn)是非Docker原生。

• Kubernetes
• Weave
• Macvlan
• Calico
• Flannel
• Contiv
• Mesos CNI

4、Flannel容器網(wǎng)絡(luò)：

Flannel之所以可以搭建kubernets依賴的底層網(wǎng)絡(luò)，是因?yàn)樗梢詫?shí)現(xiàn)以下兩點(diǎn)：

• 它給每個(gè)node上的docker容器分配相互不想沖突的IP地址;
• 它能給這些IP地址之間建立一個(gè)覆蓋網(wǎng)絡(luò)，同過覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動的傳遞到目標(biāo)容器內(nèi)。

Flannel介紹

• Flannel是CoreOS團(tuán)隊(duì)針對Kubernetes設(shè)計(jì)的一個(gè)網(wǎng)絡(luò)規(guī)劃服務(wù)，簡單來說，它的功能是讓集群中的不同節(jié)點(diǎn)主機(jī)創(chuàng)建的Docker容器都具有全集群唯一的虛擬IP地址。
• 在默認(rèn)的Docker配置中，每個(gè)節(jié)點(diǎn)上的Docker服務(wù)會分別負(fù)責(zé)所在節(jié)點(diǎn)容器的IP分配。這樣導(dǎo)致的一個(gè)問題是，不同節(jié)點(diǎn)上容器可能獲得相同的內(nèi)外IP地址。并使這些容器之間能夠之間通過IP地址相互找到，也就是相互ping通。
• Flannel的設(shè)計(jì)目的就是為集群中的所有節(jié)點(diǎn)重新規(guī)劃IP地址的使用規(guī)則，從而使得不同節(jié)點(diǎn)上的容器能夠獲得“同屬一個(gè)內(nèi)網(wǎng)”且”不重復(fù)的”IP地址，并讓屬于不同節(jié)點(diǎn)上的容器能夠直接通過內(nèi)網(wǎng)IP通信。
• Flannel實(shí)質(zhì)上是一種“覆蓋網(wǎng)絡(luò)(overlaynetwork)”，也就是將TCP數(shù)據(jù)包裝在另一種網(wǎng)絡(luò)包里面進(jìn)行路由轉(zhuǎn)發(fā)和通信，目前已經(jīng)支持udp、vxlan、host-gw、aws-vpc、gce和alloc路由等數(shù)據(jù)轉(zhuǎn)發(fā)方式，默認(rèn)的節(jié)點(diǎn)間數(shù)據(jù)通信方式是UDP轉(zhuǎn)發(fā)。 

5、Calico容器網(wǎng)絡(luò)：

Calico介紹

• Calico是一個(gè)純3層的數(shù)據(jù)中心網(wǎng)絡(luò)方案，而且無縫集成像OpenStack這種IaaS云架構(gòu)，能夠提供可控的VM、容器、裸機(jī)之間的IP通信。Calico不使用重疊網(wǎng)絡(luò)比如flannel和libnetwork重疊網(wǎng)絡(luò)驅(qū)動，它是一個(gè)純?nèi)龑拥姆椒?，使用虛擬路由代替虛擬交換，每一臺虛擬路由通過BGP協(xié)議傳播可達(dá)信息(路由)到剩余數(shù)據(jù)中心。
• Calico在每一個(gè)計(jì)算節(jié)點(diǎn)利用Linux Kernel實(shí)現(xiàn)了一個(gè)高效的vRouter來負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)，而每個(gè)vRouter通過BGP協(xié)議負(fù)責(zé)把自己上運(yùn)行的workload的路由信息像整個(gè)Calico網(wǎng)絡(luò)內(nèi)傳播——小規(guī)模部署可以直接互聯(lián)，大規(guī)模下可通過指定的BGP route reflector來完成。
• Calico節(jié)點(diǎn)組網(wǎng)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)(無論是L2或者L3)，不需要額外的NAT，隧道或者Overlay Network。
• Calico基于iptables還提供了豐富而靈活的網(wǎng)絡(luò)Policy，保證通過各個(gè)節(jié)點(diǎn)上的ACLs來提供Workload的多租戶隔離、安全組以及其他可達(dá)性限制等功能。

Calico架構(gòu)圖

五、網(wǎng)絡(luò)開源組件性能對比分析

性能對比分析：

性能對比總結(jié)：

CalicoBGP 方案最好，不能用 BGP 也可以考慮 Calico ipip tunnel 方案;如果是 Coreos 系又能開 udp offload，flannel 是不錯(cuò)的選擇;Docker 原生Overlay還有很多需要改進(jìn)的地方。

本文標(biāo)題：Kubernetes研究：網(wǎng)絡(luò)原理及方案（網(wǎng)絡(luò)原理基礎(chǔ)經(jīng)典版）
轉(zhuǎn)載來源：http://uogjgqi.cn/article/dhssccg.html