這篇文章給大家介紹Kubernetes中的網(wǎng)絡(luò)原理解析該怎么理解，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
創(chuàng)新互聯(lián)公司主要業(yè)務(wù)有網(wǎng)站營銷策劃、成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、微信公眾號開發(fā)、小程序開發(fā)、H5響應(yīng)式網(wǎng)站、程序開發(fā)等業(yè)務(wù)。一次合作終身朋友，是我們奉行的宗旨；我們不僅僅把客戶當客戶，還把客戶視為我們的合作伙伴，在開展業(yè)務(wù)的過程中，公司還積累了豐富的行業(yè)經(jīng)驗、網(wǎng)絡(luò)營銷推廣資源和合作伙伴關(guān)系資源，并逐漸建立起規(guī)范的客戶服務(wù)和保障體系。
覆蓋?絡(luò)(overlay network)是將TCP數(shù)據(jù)包裝在另?種?絡(luò)包??進?路由轉(zhuǎn)發(fā)和通信的技術(shù)。Overlay?絡(luò)不是默認必須的，但是它們在特定場景下?常有?。?如當我們沒有?夠的IP空間，或者?絡(luò)?法處理額外路由，抑或當我們需要Overlay提供的某些額外管理特性。?個常?的場景是當云提供商的路由表能處理的路由數(shù)是有限制時，例如AWS路由表最多?持50條路由才不?于影響?絡(luò)性能。因此如果我們有超過50個Kubernetes節(jié)點， AWS路由表將不夠。這種情況下，使?Overlay?絡(luò)將幫到我們。
本質(zhì)上來說， Overlay就是在跨節(jié)點的本地?絡(luò)上的包中再封裝?層包。你可能不想使?Overlay?絡(luò)，因為它會帶來由封裝和解封所有報?引起的時延和復(fù)雜度開銷。通常這是不必要的，因此我們應(yīng)當在知道為什么我們需要它時才使?它。
為了理解Overlay?絡(luò)中流量的流向，我們拿Flannel做例?，它是CoreOS 的?個開源項?。Flannel通過給每臺宿主機分配?個??的?式為容器提供虛擬?絡(luò)，它基于Linux TUN/TAP，使?UDP封裝IP包來創(chuàng)建overlay?絡(luò)，并借助etcd維護?絡(luò)的分配情況。
Kubernetes Node with route table (通過Flannel Overlay網(wǎng)絡(luò)進行跨節(jié)點的Pod-to-Pod通信)
這?我們注意到它和之前我們看到的設(shè)施是?樣的，只是在root netns中新增了?個虛擬的以太?設(shè)備，稱為flannel0。它是虛擬擴展?絡(luò)Virtual Extensible LAN（VXLAN）的?種實現(xiàn)，但是在Linux上，它只是另?個?絡(luò)接?。
從pod1到pod4（在不同節(jié)點）的數(shù)據(jù)包的流向類似如下：
1）它由pod1中netns的eth0??離開，通過vethxxx進?root netns。
2）然后被傳到cbr0， cbr0通過發(fā)送ARP請求來找到?標地址。
3）數(shù)據(jù)封裝
3a. 由于本節(jié)點上沒有Pod擁有pod4的IP地址，因此?橋把數(shù)據(jù)包發(fā)送給了flannel0，因為節(jié)點的路由表上flannel0被配成了Pod?段的?標地址。
3b. flanneld daemon和Kubernetes apiserver或者底層的etcd通信，它知道所有的Pod IP，并且知道它們在哪個節(jié)點上。因此Flannel創(chuàng)建了Pod IP和Node IP之間的映射（在?戶空間）。flannel0取到這個包，并在其上再??個UDP包封裝起來，該UDP包頭部的源和?的IP分別被改成了對應(yīng)節(jié)點的IP，然后發(fā)送這個新包到特定的VXLAN端?（通常是8472）。
Packet-in-packet encapsulation（notice the packet is encapsulated from 3c to 6b in previous diagram）
盡管這個映射發(fā)?在?戶空間，真實的封裝以及數(shù)據(jù)的流動發(fā)?在內(nèi)核空間，因此仍然是很快的。
3c. 封裝后的包通過eth0發(fā)送出去，因為它涉及了節(jié)點間的路由流量。
4. 包帶著節(jié)點IP信息作為源和?的地址離開本節(jié)點。
5. 云提供商的路由表已經(jīng)知道了如何在節(jié)點間發(fā)送報?，因此該報?被發(fā)送到?標地址node2。
6. 數(shù)據(jù)解包
6a. 包到達node2的eth0?卡，由于?標端?是特定的VXLAN端?，內(nèi)核將報?發(fā)送給了
flannel0。
6b. flannel0解封報?，并將其發(fā)送到 root 命名空間下。從這?開始，報?的路徑和我們之前在Part1 中看到的?Overlay?絡(luò)就是?致的了。
6c. 由于IP forwarding開啟著，內(nèi)核按照路由表將報?轉(zhuǎn)發(fā)給了cbr0。
7. ?橋獲取到了包，發(fā)送ARP請求，發(fā)現(xiàn)?標IP屬于vethyyy。
8. 包跨過管道對到達pod4
這就是Kubernetes中Overlay?絡(luò)的?作?式，雖然不同的實現(xiàn)還是會有細微的差別。有個常?的誤區(qū)是，當我們使?Kubernetes，我們就不得不使?Overlay?絡(luò)。事實是，這完全依賴于特定場景。因此請確保在確實需要的場景下才使?。
由于Kubernetes（更通?的說法是分布式系統(tǒng)）天?具有不斷變化的特性，因此它的Pod（以及Pod的IP）總是在改變。變化的原因可以是針對不可預(yù)測的Pod或節(jié)點崩潰?進?的滾動升級和擴展。這使得Pod IP不能直接?于通信。我們看?下Kubernetes Service，它是?個虛擬IP，并伴隨著?組Pod IP作為Endpoint（通過標簽選擇器識別）。它們充當虛擬負載均衡器，其IP保持不變，?后端Pod IP可能會不斷變化。
Kubernetes service對象中的label選擇器
整個虛擬IP的實現(xiàn)實際上是?組iptables（最新版本可以選擇使?IPVS，但這是另?個討論）規(guī)則，由Kubernetes組件kube-proxy管理。這個名字現(xiàn)在實際上是誤導(dǎo)性的。它在v 1.0之前確實是?個代理，并且由于其實現(xiàn)是內(nèi)核空間和?戶空間之間的不斷復(fù)制，它變得?常耗費資源并且速度較慢。現(xiàn)在，它只是?個控制器，就像Kubernetes中的許多其它控制器?樣，它watch api serverendpoint的更改并相應(yīng)地更新iptables規(guī)則。
Iptables DNAT
有了這些iptables規(guī)則，每當數(shù)據(jù)包發(fā)往Service IP時，它就進?DNAT（DNAT=?標?絡(luò)地址轉(zhuǎn)換）操作，這意味著?標IP從Service IP更改為其中?個Endpoint - Pod IP - 由iptables隨機選擇。這可確保負載均勻分布在后端Pod中。
conntrack表中的5元組條?
當這個DNAT發(fā)?時，這個信息存儲在conntrack中——Linux連接跟蹤表（iptables規(guī)則5元組轉(zhuǎn)譯并完成存儲：protocol， srcIP， srcPort， dstIP， dstPort）。這樣當請求回來時，它可以un-DNAT，這意味著將源IP從Pod IP更改為Service IP。這樣，客戶端就不?關(guān)?后臺如何處理數(shù)據(jù)包流。
因此通過使?Kubernetes Service，我們可以使?相同的端??不會發(fā)?任何沖突（因為我們可以將端?重新映射到Endpoint）。這使服務(wù)發(fā)現(xiàn)變得?常容易。我們可以使?內(nèi)部DNS并對服務(wù)主機名進?硬編碼。
我們甚?可以使?Kubernetes提供的service主機和端?的環(huán)境變量來完成服務(wù)發(fā)現(xiàn)。
專家建議：采取第?種?法，你可節(jié)省不必要的DNS調(diào)?，但是由于環(huán)境變量存在創(chuàng)建順序的局限性（環(huán)境變量中不包含后來創(chuàng)建的服務(wù)），推薦使?DNS來進?服務(wù)名解析。
到?前為?我們討論的Kubernetes Service是在?個集群內(nèi)?作。但是，在?多數(shù)實際情況中，應(yīng)?程序需要訪問?些外部api/website。通常，節(jié)點可以同時具有私有IP和公共IP。對于互聯(lián)?訪問，這些公共和私有IP存在某種1：1的NAT，特別是在云環(huán)境中。對于從節(jié)點到某些外部IP的普通通信，源IP從節(jié)點的專?IP更改為其出站數(shù)據(jù)包的公共IP，?站的響應(yīng)數(shù)據(jù)包則剛好相反。但是，當Pod發(fā)出與外部IP的連接時，源IP是Pod IP，云提供商的NAT機制不知道該IP。因此它將丟棄具有除節(jié)點IP之外的源IP的數(shù)據(jù)包。
因此你可能也猜對了，我們將使?更多的iptables！這些規(guī)則也由kube-proxy添加，執(zhí)?SNAT（源?絡(luò)地址轉(zhuǎn)換），即IP MASQUERADE（IP偽裝）。它告訴內(nèi)核使?此數(shù)據(jù)包發(fā)出的?絡(luò)接?的IP，代替源Pod IP同時保留conntrack條?以進?反SNAT操作。
到?前為??切都很好。Pod可以互相交談，也可以訪問互聯(lián)?。但我們?nèi)匀蝗鄙訇P(guān)鍵部分 - 為?戶請求流量提供服務(wù)。截??前，有兩種主要?法可以做到這?點：
NodePort /云負載均衡器（L4 - IP和端?）
將服務(wù)類型設(shè)置為NodePort默認會為服務(wù)分配范圍為30000-33000d的nodePort。即使在特定節(jié)點上沒有運?Pod，此nodePort也會在每個節(jié)點上打開。此NodePort上的?站流量將再次使?iptables發(fā)送到其中?個Pod（該Pod甚?可能在其它節(jié)點上?。?。
云環(huán)境中的LoadBalancer服務(wù)類型將在所有節(jié)點之前創(chuàng)建云負載均衡器（例如ELB），命中相同的nodePort。
Ingress（L7 - HTTP / TCP）
許多不同的?具，如Nginx， Traefik， HAProxy等，保留了http主機名/路徑和各?后端的映射。通常這是基于負載均衡器和nodePort的流量??點，其優(yōu)點是我們可以有?個??處理所有服務(wù)的?站流量，?不需要多個nodePort和負載均衡器。
可以把它想象為Pod的安全組/ ACL。NetworkPolicy規(guī)則允許/拒絕跨Pod的流量。確切的實現(xiàn)取決于?絡(luò)層/CNI，但?多數(shù)只使?iptables。
?前為?就這樣了。在前?的部分中，我們研究了Kubernetes?絡(luò)的基礎(chǔ)以及overlay?絡(luò)的?作原理?，F(xiàn)在我們知道Service抽象是如何在?個動態(tài)集群內(nèi)起作?并使服務(wù)發(fā)現(xiàn)變得?常容易。我們還介紹了出站和?站流量的?作原理以及?絡(luò)策略如何對集群內(nèi)的安全性起作?。
關(guān)于Kubernetes中的網(wǎng)絡(luò)原理解析該怎么理解就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
