亚洲激情专区-91九色丨porny丨老师-久久久久久久女国产乱让韩-国产精品午夜小视频观看

溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

Kubernetes中的網絡原理解析該怎么理解

發布時間:2021-11-22 16:39:30 來源:億速云 閱讀:135 作者:柒染 欄目:云計算

這篇文章給大家介紹Kubernetes中的網絡原理解析該怎么理解,內容非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。

01 覆蓋網絡

覆蓋?絡(overlay network)是將TCP數據包裝在另?種?絡包??進?路由轉發和通信的技術。Overlay?絡不是默認必須的,但是它們在特定場景下?常有?。?如當我們沒有?夠的IP空間,或者?絡?法處理額外路由,抑或當我們需要Overlay提供的某些額外管理特性。?個常?的場景是當云提供商的路由表能處理的路由數是有限制時,例如AWS路由表最多?持50條路由才不?于影響?絡性能。因此如果我們有超過50個Kubernetes節點, AWS路由表將不夠。這種情況下,使?Overlay?絡將幫到我們。

本質上來說, Overlay就是在跨節點的本地?絡上的包中再封裝?層包。你可能不想使?Overlay?絡,因為它會帶來由封裝和解封所有報?引起的時延和復雜度開銷。通常這是不必要的,因此我們應當在知道為什么我們需要它時才使?它。

為了理解Overlay?絡中流量的流向,我們拿Flannel做例?,它是CoreOS 的?個開源項?。Flannel通過給每臺宿主機分配?個??的?式為容器提供虛擬?絡,它基于Linux TUN/TAP,使?UDP封裝IP包來創建overlay?絡,并借助etcd維護?絡的分配情況。

Kubernetes中的網絡原理解析該怎么理解

Kubernetes Node with route table (通過Flannel Overlay網絡進行跨節點的Pod-to-Pod通信)

這?我們注意到它和之前我們看到的設施是?樣的,只是在root netns中新增了?個虛擬的以太?設備,稱為flannel0。它是虛擬擴展?絡Virtual Extensible LAN(VXLAN)的?種實現,但是在Linux上,它只是另?個?絡接?。

從pod1到pod4(在不同節點)的數據包的流向類似如下:

1)它由pod1中netns的eth0??離開,通過vethxxx進?root netns。
2)然后被傳到cbr0, cbr0通過發送ARP請求來找到?標地址。
3)數據封裝

3a. 由于本節點上沒有Pod擁有pod4的IP地址,因此?橋把數據包發送給了flannel0,因為節點的路由表上flannel0被配成了Pod?段的?標地址。

3b. flanneld daemon和Kubernetes apiserver或者底層的etcd通信,它知道所有的Pod IP,并且知道它們在哪個節點上。因此Flannel創建了Pod IP和Node IP之間的映射(在?戶空間)。flannel0取到這個包,并在其上再??個UDP包封裝起來,該UDP包頭部的源和?的IP分別被改成了對應節點的IP,然后發送這個新包到特定的VXLAN端?(通常是8472)。

Kubernetes中的網絡原理解析該怎么理解

Packet-in-packet encapsulation(notice the packet is encapsulated from 3c to 6b in previous diagram)

盡管這個映射發?在?戶空間,真實的封裝以及數據的流動發?在內核空間,因此仍然是很快的。

3c. 封裝后的包通過eth0發送出去,因為它涉及了節點間的路由流量。

4. 包帶著節點IP信息作為源和?的地址離開本節點。
5. 云提供商的路由表已經知道了如何在節點間發送報?,因此該報?被發送到?標地址node2。
6. 數據解包

6a. 包到達node2的eth0?卡,由于?標端?是特定的VXLAN端?,內核將報?發送給了
flannel0。
6b. flannel0解封報?,并將其發送到 root 命名空間下。從這?開始,報?的路徑和我們之前在Part1 中看到的?Overlay?絡就是?致的了。
6c. 由于IP forwarding開啟著,內核按照路由表將報?轉發給了cbr0。

7. ?橋獲取到了包,發送ARP請求,發現?標IP屬于vethyyy。
8. 包跨過管道對到達pod4

這就是Kubernetes中Overlay?絡的?作?式,雖然不同的實現還是會有細微的差別。有個常?的誤區是,當我們使?Kubernetes,我們就不得不使?Overlay?絡。事實是,這完全依賴于特定場景。因此請確保在確實需要的場景下才使?。

02動態集群

由于Kubernetes(更通?的說法是分布式系統)天?具有不斷變化的特性,因此它的Pod(以及Pod的IP)總是在改變。變化的原因可以是針對不可預測的Pod或節點崩潰?進?的滾動升級和擴展。這使得Pod IP不能直接?于通信。我們看?下Kubernetes Service,它是?個虛擬IP,并伴隨著?組Pod IP作為Endpoint(通過標簽選擇器識別)。它們充當虛擬負載均衡器,其IP保持不變,?后端Pod IP可能會不斷變化。

Kubernetes中的網絡原理解析該怎么理解

Kubernetes service對象中的label選擇器

整個虛擬IP的實現實際上是?組iptables(最新版本可以選擇使?IPVS,但這是另?個討論)規則,由Kubernetes組件kube-proxy管理。這個名字現在實際上是誤導性的。它在v 1.0之前確實是?個代理,并且由于其實現是內核空間和?戶空間之間的不斷復制,它變得?常耗費資源并且速度較慢。現在,它只是?個控制器,就像Kubernetes中的許多其它控制器?樣,它watch api serverendpoint的更改并相應地更新iptables規則。

Kubernetes中的網絡原理解析該怎么理解

Iptables DNAT

有了這些iptables規則,每當數據包發往Service IP時,它就進?DNAT(DNAT=?標?絡地址轉換)操作,這意味著?標IP從Service IP更改為其中?個Endpoint - Pod IP - 由iptables隨機選擇。這可確保負載均勻分布在后端Pod中。

Kubernetes中的網絡原理解析該怎么理解

conntrack表中的5元組條?

當這個DNAT發?時,這個信息存儲在conntrack中——Linux連接跟蹤表(iptables規則5元組轉譯并完成存儲:protocol, srcIP, srcPort, dstIP, dstPort)。這樣當請求回來時,它可以un-DNAT,這意味著將源IP從Pod IP更改為Service IP。這樣,客戶端就不?關?后臺如何處理數據包流。

因此通過使?Kubernetes Service,我們可以使?相同的端??不會發?任何沖突(因為我們可以將端?重新映射到Endpoint)。這使服務發現變得?常容易。我們可以使?內部DNS并對服務主機名進?硬編碼。

我們甚?可以使?Kubernetes提供的service主機和端?的環境變量來完成服務發現。

專家建議:采取第?種?法,你可節省不必要的DNS調?,但是由于環境變量存在創建順序的局限性(環境變量中不包含后來創建的服務),推薦使?DNS來進?服務名解析。

2.1 出站流量

到?前為?我們討論的Kubernetes Service是在?個集群內?作。但是,在?多數實際情況中,應?程序需要訪問?些外部api/website。通常,節點可以同時具有私有IP和公共IP。對于互聯?訪問,這些公共和私有IP存在某種1:1的NAT,特別是在云環境中。對于從節點到某些外部IP的普通通信,源IP從節點的專?IP更改為其出站數據包的公共IP,?站的響應數據包則剛好相反。但是,當Pod發出與外部IP的連接時,源IP是Pod IP,云提供商的NAT機制不知道該IP。因此它將丟棄具有除節點IP之外的源IP的數據包。

因此你可能也猜對了,我們將使?更多的iptables!這些規則也由kube-proxy添加,執?SNAT(源?絡地址轉換),即IP MASQUERADE(IP偽裝)。它告訴內核使?此數據包發出的?絡接?的IP,代替源Pod IP同時保留conntrack條?以進?反SNAT操作。

2.2 入站流量

到?前為??切都很好。Pod可以互相交談,也可以訪問互聯?。但我們仍然缺少關鍵部分 - 為?戶請求流量提供服務。截??前,有兩種主要?法可以做到這?點:

  • NodePort /云負載均衡器(L4 - IP和端?)

將服務類型設置為NodePort默認會為服務分配范圍為30000-33000d的nodePort。即使在特定節點上沒有運?Pod,此nodePort也會在每個節點上打開。此NodePort上的?站流量將再次使?iptables發送到其中?個Pod(該Pod甚?可能在其它節點上!)。

云環境中的LoadBalancer服務類型將在所有節點之前創建云負載均衡器(例如ELB),命中相同的nodePort。

  • Ingress(L7 - HTTP / TCP)

許多不同的?具,如Nginx, Traefik, HAProxy等,保留了http主機名/路徑和各?后端的映射。通常這是基于負載均衡器和nodePort的流量??點,其優點是我們可以有?個??處理所有服務的?站流量,?不需要多個nodePort和負載均衡器。

2.3 網站策略

可以把它想象為Pod的安全組/ ACL。NetworkPolicy規則允許/拒絕跨Pod的流量。確切的實現取決于?絡層/CNI,但?多數只使?iptables。

?前為?就這樣了。在前?的部分中,我們研究了Kubernetes?絡的基礎以及overlay?絡的?作原理。現在我們知道Service抽象是如何在?個動態集群內起作?并使服務發現變得?常容易。我們還介紹了出站和?站流量的?作原理以及?絡策略如何對集群內的安全性起作?。

關于Kubernetes中的網絡原理解析該怎么理解就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。

向AI問一下細節

免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

AI

梓潼县| 长汀县| 罗平县| 罗城| 若羌县| 纳雍县| 蒙山县| 宣城市| 克山县| 永仁县| 绍兴县| 石渠县| 磴口县| 永平县| 昭苏县| 肃宁县| 延津县| 会宁县| 阳信县| 凭祥市| 西林县| 萨嘎县| 浪卡子县| 康马县| 隆林| 库尔勒市| 天津市| 承德市| 伊宁县| 乌什县| 旺苍县| 中山市| 嵊泗县| 清徐县| 四川省| 杭州市| 元朗区| 铜鼓县| 玉树县| 蓬莱市| 易门县|