【Kubernetes系列】第11篇 網(wǎng)絡(luò)原理解析（下篇）

3. 覆蓋網(wǎng)絡(luò) - Overlay Network

覆蓋網(wǎng)絡(luò)(overlay network)是將TCP數(shù)據(jù)包裝在另一種網(wǎng)絡(luò)包里面進(jìn)行路由轉(zhuǎn)發(fā)和通信的技術(shù)。Overlay網(wǎng)絡(luò)不是默認(rèn)必須的，但是它們?cè)谔囟▓?chǎng)景下非常有用。比如當(dāng)我們沒有足夠的IP空間，或者網(wǎng)絡(luò)無法處理額外路由，抑或當(dāng)我們需要Overlay提供的某些額外管理特性。一個(gè)常見的場(chǎng)景是當(dāng)云提供商的路由表能處理的路由數(shù)是有限制時(shí)，例如AWS路由表最多支持50條路由才不至于影響網(wǎng)絡(luò)性能。因此如果我們有超過50個(gè)Kubernetes節(jié)點(diǎn)，AWS路由表將不夠。這種情況下，使用Overlay網(wǎng)絡(luò)將幫到我們。

本質(zhì)上來說，Overlay就是在跨節(jié)點(diǎn)的本地網(wǎng)絡(luò)上的包中再封裝一層包。你可能不想使用Overlay網(wǎng)絡(luò)，因?yàn)樗鼤?huì)帶來由封裝和解封所有報(bào)文引起的時(shí)延和復(fù)雜度開銷。通常這是不必要的，因此我們應(yīng)當(dāng)在知道為什么我們需要它時(shí)才使用它。

為了理解Overlay網(wǎng)絡(luò)中流量的流向，我們拿Flannel做例子，它是CoreOS 的一個(gè)開源項(xiàng)目。Flannel通過給每臺(tái)宿主機(jī)分配一個(gè)子網(wǎng)的方式為容器提供虛擬網(wǎng)絡(luò)，它基于Linux TUN/TAP，使用UDP封裝IP包來創(chuàng)建overlay網(wǎng)絡(luò)，并借助etcd維護(hù)網(wǎng)絡(luò)的分配情況。

cdn.xitu.io/2019/11/19/16e8316586e8fdd4?w=2000&h=929&f=gif&s=1472688">

Kubernetes Node with route table?
(通過Flannel Overlay網(wǎng)絡(luò)進(jìn)行跨節(jié)點(diǎn)的Pod-to-Pod通信)

這里我們注意到它和之前我們看到的設(shè)施是一樣的，只是在root netns中新增了一個(gè)虛擬的以太網(wǎng)設(shè)備，稱為flannel0。它是虛擬擴(kuò)展網(wǎng)絡(luò)Virtual Extensible LAN（VXLAN）的一種實(shí)現(xiàn)，但是在Linux上，它只是另一個(gè)網(wǎng)絡(luò)接口。

從pod1到pod4（在不同節(jié)點(diǎn)）的數(shù)據(jù)包的流向類似如下：

1.它由pod1中netns的eth0網(wǎng)口離開，通過vethxxx進(jìn)入root netns。

2.然后被傳到cbr0，cbr0通過發(fā)送ARP請(qǐng)求來找到目標(biāo)地址。

3.數(shù)據(jù)封裝

*a. 由于本節(jié)點(diǎn)上沒有Pod擁有pod4的IP地址，因此網(wǎng)橋把數(shù)據(jù)包發(fā)送給了flannel0，因?yàn)楣?jié)點(diǎn)的路由表上flannel0被配成了Pod網(wǎng)段的目標(biāo)地址。

*b. flanneld daemon和Kubernetes apiserver或者底層的etcd通信，它知道所有的Pod IP，并且知道它們?cè)谀膫€(gè)節(jié)點(diǎn)上。因此Flannel創(chuàng)建了Pod IP和Node IP之間的映射（在用戶空間）。flannel0取到這個(gè)包，并在其上再用一個(gè)UDP包封裝起來，該UDP包頭部的源和目的IP分別被改成了對(duì)應(yīng)節(jié)點(diǎn)的IP，然后發(fā)送這個(gè)新包到特定的VXLAN端口（通常是8472）。

Packet-in-packet encapsulation?
（notice the packet is encapsulated from 3c to 6b in previous diagram）

盡管這個(gè)映射發(fā)生在用戶空間，真實(shí)的封裝以及數(shù)據(jù)的流動(dòng)發(fā)生在內(nèi)核空間，因此仍然是很快的

*c. 封裝后的包通過eth0發(fā)送出去，因?yàn)樗婕傲斯?jié)點(diǎn)間的路由流量。

4.包帶著節(jié)點(diǎn)IP信息作為源和目的地址離開本節(jié)點(diǎn)。

5.云提供商的路由表已經(jīng)知道了如何在節(jié)點(diǎn)間發(fā)送報(bào)文，因此該報(bào)文被發(fā)送到目標(biāo)地址node2。

6.數(shù)據(jù)解包

*a. 包到達(dá)node2的eth0網(wǎng)卡，由于目標(biāo)端口是特定的VXLAN端口，內(nèi)核將報(bào)文發(fā)送給了 flannel0。?

*b. flannel0解封報(bào)文，并將其發(fā)送到 root 命名空間下。從這里開始，報(bào)文的路徑和我們之前在Part 1 中看到的非Overlay網(wǎng)絡(luò)就是一致的了。?

*c. 由于IP forwarding開啟著，內(nèi)核按照路由表將報(bào)文轉(zhuǎn)發(fā)給了cbr0。

7.網(wǎng)橋獲取到了包，發(fā)送ARP請(qǐng)求，發(fā)現(xiàn)目標(biāo)IP屬于vethyyy。

8.包跨過管道對(duì)到達(dá)pod4

這就是Kubernetes中Overlay網(wǎng)絡(luò)的工作方式，雖然不同的實(shí)現(xiàn)還是會(huì)有細(xì)微的差別。有個(gè)常見的誤區(qū)是，當(dāng)我們使用Kubernetes，我們就不得不使用Overlay網(wǎng)絡(luò)。事實(shí)是，這完全依賴于特定場(chǎng)景。因此請(qǐng)確保在確實(shí)需要的場(chǎng)景下才使用。

4. 動(dòng)態(tài)集群

由于Kubernetes（更通用的說法是分布式系統(tǒng)）天生具有不斷變化的特性，因此它的Pod（以及Pod的IP）總是在改變。變化的原因可以是針對(duì)不可預(yù)測(cè)的Pod或節(jié)點(diǎn)崩潰而進(jìn)行的滾動(dòng)升級(jí)和擴(kuò)展。這使得Pod IP不能直接用于通信。

我們看一下Kubernetes Service，它是一個(gè)虛擬IP，并伴隨著一組Pod IP作為Endpoint（通過標(biāo)簽選擇器識(shí)別）。它們充當(dāng)虛擬負(fù)載均衡器，其IP保持不變，而后端Pod IP可能會(huì)不斷變化。

Kubernetes service對(duì)象中的label選擇器

整個(gè)虛擬IP的實(shí)現(xiàn)實(shí)際上是一組iptables（最新版本可以選擇使用IPVS，但這是另一個(gè)討論）規(guī)則，由Kubernetes組件kube-proxy管理。 這個(gè)名字現(xiàn)在實(shí)際上是誤導(dǎo)性的。 它在v 1.0之前確實(shí)是一個(gè)代理，并且由于其實(shí)現(xiàn)是內(nèi)核空間和用戶空間之間的不斷復(fù)制，它變得非常耗費(fèi)資源并且速度較慢。 現(xiàn)在，它只是一個(gè)控制器，就像Kubernetes中的許多其它控制器一樣，它watch api server的endpoint的更改并相應(yīng)地更新iptables規(guī)則。

Iptables DNAT

有了這些iptables規(guī)則，每當(dāng)數(shù)據(jù)包發(fā)往Service IP時(shí)，它就進(jìn)行DNAT（DNAT=目標(biāo)網(wǎng)絡(luò)地址轉(zhuǎn)換）操作，這意味著目標(biāo)IP從Service IP更改為其中一個(gè)Endpoint - Pod IP - 由iptables隨機(jī)選擇。這可確保負(fù)載均勻分布在后端Pod中。

conntrack表中的5元組條目

當(dāng)這個(gè)DNAT發(fā)生時(shí)，這個(gè)信息存儲(chǔ)在conntrack中——Linux連接跟蹤表（iptables規(guī)則5元組轉(zhuǎn)譯并完成存儲(chǔ)：protocol，srcIP，srcPort，dstIP，dstPort）。 這樣當(dāng)請(qǐng)求回來時(shí)，它可以u(píng)n-DNAT，這意味著將源IP從Pod IP更改為Service IP。 這樣，客戶端就不用關(guān)心后臺(tái)如何處理數(shù)據(jù)包流。

因此通過使用Kubernetes Service，我們可以使用相同的端口而不會(huì)發(fā)生任何沖突（因?yàn)槲覀兛梢詫⒍丝谥匦掠成涞紼ndpoint）。 這使服務(wù)發(fā)現(xiàn)變得非常容易。 我們可以使用內(nèi)部DNS并對(duì)服務(wù)主機(jī)名進(jìn)行硬編碼。 我們甚至可以使用Kubernetes提供的service主機(jī)和端口的環(huán)境變量來完成服務(wù)發(fā)現(xiàn)。

專家建議：?采取第二種方法，你可節(jié)省不必要的DNS調(diào)用，但是由于環(huán)境變量存在創(chuàng)建順序的局限性（環(huán)境變量中不包含后來創(chuàng)建的服務(wù)），推薦使用DNS來進(jìn)行服務(wù)名解析。

4.1 出站流量

到目前為止我們討論的Kubernetes Service是在一個(gè)集群內(nèi)工作。但是，在大多數(shù)實(shí)際情況中，應(yīng)用程序需要訪問一些外部api/website。

通常，節(jié)點(diǎn)可以同時(shí)具有私有IP和公共IP。對(duì)于互聯(lián)網(wǎng)訪問，這些公共和私有IP存在某種1：1的NAT，特別是在云環(huán)境中。

對(duì)于從節(jié)點(diǎn)到某些外部IP的普通通信，源IP從節(jié)點(diǎn)的專用IP更改為其出站數(shù)據(jù)包的公共IP，入站的響應(yīng)數(shù)據(jù)包則剛好相反。但是，當(dāng)Pod發(fā)出與外部IP的連接時(shí)，源IP是Pod IP，云提供商的NAT機(jī)制不知道該IP。因此它將丟棄具有除節(jié)點(diǎn)IP之外的源IP的數(shù)據(jù)包。

因此你可能也猜對(duì)了，我們將使用更多的iptables！這些規(guī)則也由kube-proxy添加，執(zhí)行SNAT（源網(wǎng)絡(luò)地址轉(zhuǎn)換），即IP MASQUERADE（IP偽裝）。它告訴內(nèi)核使用此數(shù)據(jù)包發(fā)出的網(wǎng)絡(luò)接口的IP，代替源Pod IP同時(shí)保留conntrack條目以進(jìn)行反SNAT操作。

4.2 入站流量

到目前為止一切都很好。Pod可以互相交談，也可以訪問互聯(lián)網(wǎng)。但我們?nèi)匀蝗鄙訇P(guān)鍵部分 - 為用戶請(qǐng)求流量提供服務(wù)。截至目前，有兩種主要方法可以做到這一點(diǎn)：

* NodePort /云負(fù)載均衡器（L4 - IP和端口）

將服務(wù)類型設(shè)置為NodePort默認(rèn)會(huì)為服務(wù)分配范圍為30000-33000的nodePort。即使在特定節(jié)點(diǎn)上沒有運(yùn)行Pod，此nodePort也會(huì)在每個(gè)節(jié)點(diǎn)上打開。此NodePort上的入站流量將再次使用iptables發(fā)送到其中一個(gè)Pod（該P(yáng)od甚至可能在其它節(jié)點(diǎn)上?。?/p>

云環(huán)境中的LoadBalancer服務(wù)類型將在所有節(jié)點(diǎn)之前創(chuàng)建云負(fù)載均衡器（例如ELB），命中相同的nodePort。

* Ingress（L7 - HTTP / TCP）

許多不同的工具，如Nginx，Traefik，HAProxy等，保留了http主機(jī)名/路徑和各自后端的映射。通常這是基于負(fù)載均衡器和nodePort的流量入口點(diǎn)，其優(yōu)點(diǎn)是我們可以有一個(gè)入口處理所有服務(wù)的入站流量，而不需要多個(gè)nodePort和負(fù)載均衡器。

4.3 網(wǎng)絡(luò)策略

可以把它想象為Pod的安全組/ ACL。 NetworkPolicy規(guī)則允許/拒絕跨Pod的流量。確切的實(shí)現(xiàn)取決于網(wǎng)絡(luò)層/CNI，但大多數(shù)只使用iptables。

結(jié)束語

目前為止就這樣了。 在前面的部分中，我們研究了Kubernetes網(wǎng)絡(luò)的基礎(chǔ)以及overlay網(wǎng)絡(luò)的工作原理。 現(xiàn)在我們知道Service抽象是如何在一個(gè)動(dòng)態(tài)集群內(nèi)起作用并使服務(wù)發(fā)現(xiàn)變得非常容易。我們還介紹了出站和入站流量的工作原理以及網(wǎng)絡(luò)策略如何對(duì)集群內(nèi)的安全性起作用。

參考文章

An illustrated guide to Kubernetes Networking - part1

An illustrated guide to Kubernetes Networking - part2

An illustrated guide to Kubernetes Networking - part3