云計(jì)算

作者 |?阿里巴巴高級技術(shù)專家? 葉磊

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),南州晴隆企業(yè)網(wǎng)站建設(shè),南州晴隆品牌網(wǎng)站建設(shè),網(wǎng)站定制,南州晴隆網(wǎng)站建設(shè)報(bào)價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,南州晴隆網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。一、Kubernetes 基本網(wǎng)絡(luò)模型

本文來介紹一下 Kubernetes 對網(wǎng)絡(luò)模型的一些想法。大家知道 Kubernetes 對于網(wǎng)絡(luò)具體實(shí)現(xiàn)方案，沒有什么限制，也沒有給出特別好的參考案例。Kubernetes 對一個容器網(wǎng)絡(luò)是否合格做出了限制，也就是 Kubernetes 的容器網(wǎng)絡(luò)模型。可以把它歸結(jié)為約法三章和四大目標(biāo)。

約法三章的意思是：在評價一個容器網(wǎng)絡(luò)或者設(shè)計(jì)容器網(wǎng)絡(luò)的時候，它的準(zhǔn)入條件。它需要滿足哪三條？ 才能認(rèn)為它是一個合格的網(wǎng)絡(luò)方案。 四大目標(biāo)意思是在設(shè)計(jì)這個網(wǎng)絡(luò)的拓?fù)洌O(shè)計(jì)網(wǎng)絡(luò)的具體功能的實(shí)現(xiàn)的時候，要去想清楚，能不能達(dá)成連通性等這幾大指標(biāo)。 約法三章

先來看下約法三章：

第一條：任意兩個 pod 之間其實(shí)是可以直接通信的，無需經(jīng)過顯式地使用 NAT 來接收數(shù)據(jù)和地址的轉(zhuǎn)換； 第二條：node 與 pod 之間是可以直接通信的，無需使用明顯的地址轉(zhuǎn)換； 第三條：pod 看到自己的 IP 跟別人看見它所用的IP是一樣的，中間不能經(jīng)過轉(zhuǎn)換。

后文中會講一下我個人的理解，為什么 Kubernetes 對容器網(wǎng)絡(luò)會有一些看起來武斷的模型和要求。

四大目標(biāo)

四大目標(biāo)其實(shí)是在設(shè)計(jì)一個 K8s 的系統(tǒng)為外部世界提供服務(wù)的時候，從網(wǎng)絡(luò)的角度要想清楚，外部世界如何一步一步連接到容器內(nèi)部的應(yīng)用？

外部世界和 service 之間是怎么通信的？就是有一個互聯(lián)網(wǎng)或者是公司外部的一個用戶，怎么用到 service？service 特指 K8s 里面的服務(wù)概念。 service 如何與它后端的 pod 通訊？ pod 和 pod 之間調(diào)用是怎么做到通信的？ 最后就是 pod 內(nèi)部容器與容器之間的通信？

最終要達(dá)到目標(biāo)，就是外部世界可以連接到最里面，對容器提供服務(wù)。

對基本約束的解釋

對基本約束，可以做出這樣一些解讀：因?yàn)槿萜鞯木W(wǎng)絡(luò)發(fā)展復(fù)雜性就在于它其實(shí)是寄生在 Host 網(wǎng)絡(luò)之上的。從這個角度講，可以把容器網(wǎng)絡(luò)方案大體分為?Underlay/Overlay?兩大派別：

Underlay 的標(biāo)準(zhǔn)是它與 Host 網(wǎng)絡(luò)是同層的，從外在可見的一個特征就是它是不是使用了 Host 網(wǎng)絡(luò)同樣的網(wǎng)段、輸入輸出基礎(chǔ)設(shè)備、容器的?IP 地址是不是需要與 Host 網(wǎng)絡(luò)取得協(xié)同（來自同一個中心分配或統(tǒng)一劃分）。這就是 Underlay； Overlay 不一樣的地方就在于它并不需要從 Host 網(wǎng)絡(luò)的 IPM 的管理的組件去申請 IP，一般來說，它只需要跟 Host 網(wǎng)絡(luò)不沖突，這個 IP 可以自由分配的。

為什么社區(qū)會提出 perPodperIP 這種簡單武斷的模型呢？我個人是覺得這樣為后面的 service 管理一些服務(wù)的跟蹤性能監(jiān)控，帶來了非常多的好處。因?yàn)橐粋€ IP 一貫到底，對 case 或者各種不大的事情都會有很大的好處。

二、Netns 探秘 Netns 究竟實(shí)現(xiàn)了什么

下面簡單講一下，Network Namespace 里面能網(wǎng)絡(luò)實(shí)現(xiàn)的內(nèi)核基礎(chǔ)。狹義上來說 runC 容器技術(shù)是不依賴于任何硬件的，它的執(zhí)行基礎(chǔ)就是它的內(nèi)核里面，進(jìn)程的內(nèi)核代表就是?task，它如果不需要隔離，那么用的是主機(jī)的空間（ namespace），并不需要特別設(shè)置的空間隔離數(shù)據(jù)結(jié)構(gòu)（ nsproxy-namespace proxy）。

相反，如果一個獨(dú)立的網(wǎng)絡(luò) proxy，或者 mount proxy，里面就要填上真正的私有數(shù)據(jù)。它可以看到的數(shù)據(jù)結(jié)構(gòu)如上圖所示。

從感官上來看一個隔離的網(wǎng)絡(luò)空間，它會擁有自己的網(wǎng)卡或者說是網(wǎng)絡(luò)設(shè)備。網(wǎng)卡可能是虛擬的，也可能是物理網(wǎng)卡，它會擁有自己的 IP 地址、IP 表和路由表、擁有自己的協(xié)議棧狀態(tài)。這里面特指就是 TCP/Ip協(xié)議棧，它會有自己的status，會有自己的 iptables、ipvs。

從整個感官上來講，這就相當(dāng)于擁有了一個完全獨(dú)立的網(wǎng)絡(luò)，它與主機(jī)網(wǎng)絡(luò)是隔離的。當(dāng)然協(xié)議棧的代碼還是公用的，只是數(shù)據(jù)結(jié)構(gòu)不相同。

Pod 與 Netns 的關(guān)系

這張圖可以清晰表明 pod 里 Netns 的關(guān)系，每個 pod 都有著獨(dú)立的網(wǎng)絡(luò)空間，pod net container 會共享這個網(wǎng)絡(luò)空間。一般 K8s 會推薦選用 Loopback 接口，在 pod net container 之間進(jìn)行通信，而所有的 container 通過 pod 的 IP 對外提供服務(wù)。另外對于宿主機(jī)上的 Root Netns，可以把它看做一個特殊的網(wǎng)絡(luò)空間，只不過它的?Pid?是1。

三、主流網(wǎng)絡(luò)方案簡介 典型的容器網(wǎng)絡(luò)實(shí)現(xiàn)方案

接下來簡單介紹一下典型的容器網(wǎng)絡(luò)實(shí)現(xiàn)方案。容器網(wǎng)絡(luò)方案可能是 K8s 里最為百花齊放的一個領(lǐng)域，它有著各種各樣的實(shí)現(xiàn)。容器網(wǎng)絡(luò)的復(fù)雜性，其實(shí)在于它需要跟底層 Iass 層的網(wǎng)絡(luò)做協(xié)調(diào)、需要在性能跟 IP 分配的靈活性上做一些選擇，這個方案是多種多樣的。

下面簡單介紹幾個比較主要的方案：分別是 Flannel、Calico、Canal ，最后是 WeaveNet，中間的大多數(shù)方案都是采用了跟 Calico 類似的策略路由的方法。

Flannel?是一個比較大一統(tǒng)的方案，它提供了多種的網(wǎng)絡(luò) backend。不同的 backend 實(shí)現(xiàn)了不同的拓?fù)洌梢愿采w多種場景； Calico?主要是采用了策略路由，節(jié)點(diǎn)之間采用 BGP 的協(xié)議，去進(jìn)行路由的同步。它的特點(diǎn)是功能比較豐富，尤其是對 Network Point 支持比較好，大家都知道 Calico 對底層網(wǎng)絡(luò)的要求，一般是需要 mac 地址能夠直通，不能跨二層域； 當(dāng)然也有一些社區(qū)的同學(xué)會把 Flannel 的優(yōu)點(diǎn)和 Calico 的優(yōu)點(diǎn)做一些集成。我們稱之為嫁接型的創(chuàng)新項(xiàng)目?Cilium； 最后講一下?WeaveNet，如果大家在使用中需要對數(shù)據(jù)做一些加密，可以選擇用 WeaveNet，它的動態(tài)方案可以實(shí)現(xiàn)比較好的加密。 Flannel 方案

Flannel 方案是目前使用最為普遍的。如上圖所示，可以看到一個典型的容器網(wǎng)方案。它首先要解決的是 container 的包如何到達(dá) Host，這里采用的是加一個 Bridge 的方式。它的 backend 其實(shí)是獨(dú)立的，也就是說這個包如何離開 Host，是采用哪種封裝方式，還是不需要封裝，都是可選擇的。

現(xiàn)在來介紹三種主要的 backend：

一種是用戶態(tài)的 udp，這種是最早期的實(shí)現(xiàn)； 然后是內(nèi)核的 Vxlan，這兩種都算是 overlay 的方案。Vxlan 的性能會比較好一點(diǎn)，但是它對內(nèi)核的版本是有要求的，需要內(nèi)核支持 Vxlan 的功能； 如果你的集群規(guī)模不夠大，又處于同一個二層域，也可以選擇采用 host-gw 的方式。這種方式的 backend 基本上是由一段廣播路由規(guī)則來啟動的，性能比較高。 四、Network Policy 的用處 Network Policy 基本概念

下面介紹一下 Network Policy 的概念。

剛才提到了 Kubernetes 網(wǎng)絡(luò)的基本模型是需要 pod 之間全互聯(lián)，這個將帶來一些問題：可能在一個 K8s 集群里，有一些調(diào)用鏈之間是不會直接調(diào)用的。比如說兩個部門之間，那么我希望 A 部門不要去探視到 B 部門的服務(wù)，這個時候就可以用到策略的概念。

基本上它的想法是這樣的：它采用各種選擇器（標(biāo)簽或 namespace），找到一組 pod，或者找到相當(dāng)于通訊的兩端，然后通過流的特征描述來決定它們之間是不是可以聯(lián)通，可以理解為一個白名單的機(jī)制。

在使用 Network Policy 之前，如上圖所示要注意 apiserver 需要打開一下這幾個開關(guān)。另一個更重要的是我們選用的網(wǎng)絡(luò)插件需要支持 Network Policy 的落地。大家要知道，Network Policy 只是 K8s 提供的一種對象，并沒有內(nèi)置組件做落地實(shí)施，需要取決于你選擇的容器網(wǎng)絡(luò)方案對這個標(biāo)準(zhǔn)的支持與否及完備程度，如果你選擇 Flannel 之類，它并沒有真正去落地這個 Policy，那么你試了這個也沒有什么用。

配置實(shí)例

接下來講一個配置的實(shí)例，或者說在設(shè)計(jì)一個 Network Policy 的時候要做哪些事情？我個人覺得需要決定三件事：

第一件事是控制對象，就像這個實(shí)例里面 spec 的部分。spec 里面通過 podSelector 或者 namespace 的 selector，可以選擇做特定的一組 pod 來接受我們的控制； 第二個就是對流向考慮清楚，需要控制入方向還是出方向？還是兩個方向都要控制？ 最重要的就是第三部分，如果要對選擇出來的方向加上控制對象來對它流進(jìn)行描述，具體哪一些 stream 可以放進(jìn)來，或者放出去？類比這個流特征的五元組，可以通過一些選擇器來決定哪一些可以作為我的遠(yuǎn)端，這是對象的選擇；也可以通過 IPBlock 這種機(jī)制來得到對哪些 IP 是可以放行的；最后就是哪些協(xié)議或哪些端口。其實(shí)流特征綜合起來就是一個五元組，會把特定的能夠接受的流選擇出來 。 本文總結(jié)

本文內(nèi)容到這里就結(jié)束了，我們簡單總結(jié)一下：

在 pod 的容器網(wǎng)絡(luò)中核心概念就是 IP，IP 就是每個 pod 對外通訊的地址基礎(chǔ)，必須內(nèi)外一致，符合 K8s 的模型特征；

那么在介紹網(wǎng)絡(luò)方案的時候，影響容器網(wǎng)絡(luò)性能最關(guān)鍵的就是拓?fù)洹Ｒ軌蚶斫饽愕陌说蕉耸窃趺绰?lián)通的，中間怎么從 container 到達(dá) Host，Host 出了 container 是要封裝還是解封裝？還是通過策略路由？最終到達(dá)對端是怎么解出來的？

容器網(wǎng)絡(luò)選擇和設(shè)計(jì)選擇。如果你并不清楚你的外部網(wǎng)絡(luò)，或者你需要一個普適性最強(qiáng)的方案，假設(shè)說你對 mac 是否直連不太清楚、對外部路由器的路由表能否控制也不太清楚，那么你可以選擇 Flannel 利用 Vxlan 作為 backend 的這種方案。如果你確信你的網(wǎng)絡(luò)是 2 層可直連的，你可以進(jìn)行選用 Calico 或者 Flannel-Hostgw 作為一個 backend；

最后就是對 Network Policy，在運(yùn)維和使用的時候，它是一個很強(qiáng)大的工具，可以實(shí)現(xiàn)對進(jìn)出流的精確控制。實(shí)現(xiàn)的方法我們也介紹了，要想清楚你要控制誰，然后你的流要怎么去定義。 五、思考時間

最后留一些思考，大家可以想一想：

為什么接口標(biāo)準(zhǔn)化 CNI 化了，但是容器網(wǎng)絡(luò)卻沒有一個很標(biāo)準(zhǔn)的實(shí)現(xiàn)，內(nèi)置在 K8s 里面？

Network Policy 為什么沒有一個標(biāo)準(zhǔn)的 controller 或者一個標(biāo)準(zhǔn)的實(shí)現(xiàn)，而是交給這個容器網(wǎng)絡(luò)的 owner 來提供？

有沒有可能完全不用網(wǎng)絡(luò)設(shè)備來實(shí)現(xiàn)容器網(wǎng)絡(luò)呢？考慮到現(xiàn)在有 RDMA 等有別于 TCP/IP 的這種方案。

在運(yùn)維過程中網(wǎng)絡(luò)問題比較多、也比較難排查，那么值不值得做一個開源工具，讓它可以友好的展示從 container 到 Host 之間、Host 到 Host 之間，或者說封裝及解封裝之間，各個階段的網(wǎng)絡(luò)情況，有沒有出現(xiàn)問題，能夠快速的定位。據(jù)我所知應(yīng)該現(xiàn)在是沒有這樣的工具的。

以上就是我對 K8s 容器網(wǎng)絡(luò)的基本概念、以及 Network Policy 的一些介紹。

“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)×××

當(dāng)前題目：從零開始入門K8s|Kubernetes網(wǎng)絡(luò)概念及策略控制
鏈接地址：http://chinadenli.net/article26/cjidcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計(jì)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)公司、靜態(tài)網(wǎng)站、軟件開發(fā)、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)