從零開始入門 K8s | Kubernetes 網(wǎng)絡(luò)概念及策略控制

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

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

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

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

約法三章

先來看下約法三章：

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

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

四大目標(biāo)

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

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

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

對(duì)基本約束的解釋

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

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

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

二、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）。

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

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

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

Pod 與 Netns 的關(guān)系

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

三、主流網(wǎng)絡(luò)方案簡介

典型的容器網(wǎng)絡(luò)實(shí)現(xiàn)方案

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

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

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

Flannel 方案

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

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

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

四、Network Policy 的用處

Network Policy 基本概念

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

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

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

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

配置實(shí)例

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

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

本文總結(jié)

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

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

• 那么在介紹網(wǎng)絡(luò)方案的時(shí)候，影響容器網(wǎng)絡(luò)性能最關(guān)鍵的就是拓?fù)?。要能夠理解你的包端到端是怎么?lián)通的，中間怎么從 container 到達(dá) Host，Host 出了 container 是要封裝還是解封裝？還是通過策略路由？最終到達(dá)對(duì)端是怎么解出來的？

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

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

五、思考時(shí)間

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

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

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

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

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

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

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