[[269494]]

本文將在介紹技術(shù)原理和相應(yīng)術(shù)語的基礎(chǔ)上，再集中探索與詳細(xì)對(duì)比目前***的CNI插件：

• Flannel
• Calico
• Weave

介紹

網(wǎng)絡(luò)架構(gòu)是Kubernetes中較為復(fù)雜、讓很多用戶頭疼的方面之一。Kubernetes網(wǎng)絡(luò)模型本身對(duì)某些特定的網(wǎng)絡(luò)功能有一定要求，但在實(shí)現(xiàn)方面也具有一定的靈活性。因此，業(yè)界已有不少不同的網(wǎng)絡(luò)方案，來滿足特定的環(huán)境和要求。

CNI意為容器網(wǎng)絡(luò)接口，它是一種標(biāo)準(zhǔn)的設(shè)計(jì)，為了讓用戶在容器創(chuàng)建或銷毀時(shí)都能夠更容易地配置容器網(wǎng)絡(luò)。在本文中，我們將集中探索與對(duì)比目前***的CNI插件：Flannel、Calico、Weave和Canal(技術(shù)上是多個(gè)插件的組合)。這些插件既可以確保滿足Kubernetes的網(wǎng)絡(luò)要求，又能為Kubernetes集群管理員提供他們所需的某些特定的網(wǎng)絡(luò)功能。

背景

容器網(wǎng)絡(luò)是容器選擇連接到其他容器、主機(jī)和外部網(wǎng)絡(luò)(如Internet)的機(jī)制。容器的Runtime提供了各種網(wǎng)絡(luò)模式，每種模式都會(huì)產(chǎn)生不同的體驗(yàn)。

例如，Docker默認(rèn)情況下可以為容器配置以下網(wǎng)絡(luò)：

• none：將容器添加到一個(gè)容器專門的網(wǎng)絡(luò)堆棧中，沒有對(duì)外連接。
• host：將容器添加到主機(jī)的網(wǎng)絡(luò)堆棧中，沒有隔離。
• default bridge：默認(rèn)網(wǎng)絡(luò)模式。每個(gè)容器可以通過IP地址相互連接。
• 自定義網(wǎng)橋：用戶定義的網(wǎng)橋，具有更多的靈活性、隔離性和其他便利功能。

Docker還可以讓用戶通過其他驅(qū)動(dòng)程序和插件，來配置更高級(jí)的網(wǎng)絡(luò)(包括多主機(jī)覆蓋網(wǎng)絡(luò))。

CNI的初衷是創(chuàng)建一個(gè)框架，用于在配置或銷毀容器時(shí)動(dòng)態(tài)配置適當(dāng)?shù)木W(wǎng)絡(luò)配置和資源。下面鏈接中的CNI規(guī)范概括了用于配制網(wǎng)絡(luò)的插件接口，這個(gè)接口可以讓容器運(yùn)行時(shí)與插件進(jìn)行協(xié)調(diào)：

https://github.com/containernetworking/cni/blob/master/SPEC.md

插件負(fù)責(zé)為接口配置和管理IP地址，并且通常提供與IP管理、每個(gè)容器的IP分配、以及多主機(jī)連接相關(guān)的功能。容器運(yùn)行時(shí)會(huì)調(diào)用網(wǎng)絡(luò)插件，從而在容器啟動(dòng)時(shí)分配IP地址并配置網(wǎng)絡(luò)，并在刪除容器時(shí)再次調(diào)用它以清理這些資源。

運(yùn)行時(shí)或協(xié)調(diào)器決定了容器應(yīng)該加入哪個(gè)網(wǎng)絡(luò)以及它需要調(diào)用哪個(gè)插件。然后，插件會(huì)將接口添加到容器網(wǎng)絡(luò)命名空間中，作為一個(gè)veth對(duì)的一側(cè)。接著，它會(huì)在主機(jī)上進(jìn)行更改，包括將veth的其他部分連接到網(wǎng)橋。再之后，它會(huì)通過調(diào)用單獨(dú)的IPAM(IP地址管理)插件來分配IP地址并設(shè)置路由。

在Kubernetes中，kubelet可以在適當(dāng)?shù)臅r(shí)間調(diào)用它找到的插件，來為通過kubelet啟動(dòng)的pod進(jìn)行自動(dòng)的網(wǎng)絡(luò)配置。

術(shù)語

在對(duì)CNI插件們進(jìn)行比較之前，我們可以先對(duì)網(wǎng)絡(luò)中會(huì)見到的相關(guān)術(shù)語做一個(gè)整體的了解。不論是閱讀本文，還是今后接觸到其他和CNI有關(guān)的內(nèi)容，了解一些常見術(shù)語總是非常有用的。

一些最常見的術(shù)語包括：

• 第2層網(wǎng)絡(luò)：OSI(Open Systems Interconnections，開放系統(tǒng)互連)網(wǎng)絡(luò)模型的“數(shù)據(jù)鏈路”層。第2層網(wǎng)絡(luò)會(huì)處理網(wǎng)絡(luò)上兩個(gè)相鄰節(jié)點(diǎn)之間的幀傳遞。第2層網(wǎng)絡(luò)的一個(gè)值得注意的示例是以太網(wǎng)，其中MAC表示為子層。
• 第3層網(wǎng)絡(luò)：OSI網(wǎng)絡(luò)模型的“網(wǎng)絡(luò)”層。第3層網(wǎng)絡(luò)的主要關(guān)注點(diǎn)，是在第2層連接之上的主機(jī)之間路由數(shù)據(jù)包。IPv4、IPv6和ICMP是第3層網(wǎng)絡(luò)協(xié)議的示例。
• VXLAN：代表“虛擬可擴(kuò)展LAN”。首先，VXLAN用于通過在UDP數(shù)據(jù)報(bào)中封裝第2層以太網(wǎng)幀來幫助實(shí)現(xiàn)大型云部署。VXLAN虛擬化與VLAN類似，但提供更大的靈活性和功能(VLAN僅限于4096個(gè)網(wǎng)絡(luò)ID)。VXLAN是一種封裝和覆蓋協(xié)議，可在現(xiàn)有網(wǎng)絡(luò)上運(yùn)行。
• Overlay網(wǎng)絡(luò)：Overlay網(wǎng)絡(luò)是建立在現(xiàn)有網(wǎng)絡(luò)之上的虛擬邏輯網(wǎng)絡(luò)。Overlay網(wǎng)絡(luò)通常用于在現(xiàn)有網(wǎng)絡(luò)之上提供有用的抽象，并分離和保護(hù)不同的邏輯網(wǎng)絡(luò)。
• 封裝：封裝是指在附加層中封裝網(wǎng)絡(luò)數(shù)據(jù)包以提供其他上下文和信息的過程。在overlay網(wǎng)絡(luò)中，封裝被用于從虛擬網(wǎng)絡(luò)轉(zhuǎn)換到底層地址空間，從而能路由到不同的位置(數(shù)據(jù)包可以被解封裝，并繼續(xù)到其目的地)。
• 網(wǎng)狀網(wǎng)絡(luò)：網(wǎng)狀網(wǎng)絡(luò)(Mesh network)是指每個(gè)節(jié)點(diǎn)連接到許多其他節(jié)點(diǎn)以協(xié)作路由、并實(shí)現(xiàn)更大連接的網(wǎng)絡(luò)。網(wǎng)狀網(wǎng)絡(luò)允許通過多個(gè)路徑進(jìn)行路由，從而提供更可靠的網(wǎng)絡(luò)。網(wǎng)狀網(wǎng)格的缺點(diǎn)是每個(gè)附加節(jié)點(diǎn)都會(huì)增加大量開銷。
• BGP：代表“邊界網(wǎng)關(guān)協(xié)議”，用于管理邊緣路由器之間數(shù)據(jù)包的路由方式。BGP通過考慮可用路徑，路由規(guī)則和特定網(wǎng)絡(luò)策略，幫助弄清楚如何將數(shù)據(jù)包從一個(gè)網(wǎng)絡(luò)發(fā)送到另一個(gè)網(wǎng)絡(luò)。BGP有時(shí)被用作CNI插件中的路由機(jī)制，而不是封裝的覆蓋網(wǎng)絡(luò)。

了解了技術(shù)術(shù)語和支持各類插件的各種技術(shù)之后，下面我們可以開始探索一些***的CNI插件了。

CNI比較

Flannel

鏈接：https://github.com/coreos/flannel

由CoreOS開發(fā)的項(xiàng)目Flannel，可能是最直接和***的CNI插件。它是容器編排系統(tǒng)中最成熟的網(wǎng)絡(luò)結(jié)構(gòu)示例之一，旨在實(shí)現(xiàn)更好的容器間和主機(jī)間網(wǎng)絡(luò)。隨著CNI概念的興起，F(xiàn)lannel CNI插件算是早期的入門。

與其他方案相比，F(xiàn)lannel相對(duì)容易安裝和配置。它被打包為單個(gè)二進(jìn)制文件FlannelD，許多常見的Kubernetes集群部署工具和許多Kubernetes發(fā)行版都可以默認(rèn)安裝Flannel。Flannel可以使用Kubernetes集群的現(xiàn)有etcd集群來使用API存儲(chǔ)其狀態(tài)信息，因此不需要專用的數(shù)據(jù)存儲(chǔ)。

Flannel配置第3層IPv4 Overlay網(wǎng)絡(luò)。它會(huì)創(chuàng)建一個(gè)大型內(nèi)部網(wǎng)絡(luò)，跨越集群中每個(gè)節(jié)點(diǎn)。在此Overlay網(wǎng)絡(luò)中，每個(gè)節(jié)點(diǎn)都有一個(gè)子網(wǎng)，用于在內(nèi)部分配IP地址。在配置Pod時(shí)，每個(gè)節(jié)點(diǎn)上的Docker橋接口都會(huì)為每個(gè)新容器分配一個(gè)地址。同一主機(jī)中的Pod可以使用Docker橋接進(jìn)行通信，而不同主機(jī)上的pod會(huì)使用flanneld將其流量封裝在UDP數(shù)據(jù)包中，以便路由到適當(dāng)?shù)哪繕?biāo)。

Flannel有幾種不同類型的后端可用于封裝和路由。默認(rèn)和推薦的方法是使用VXLAN，因?yàn)閂XLAN性能更良好并且需要的手動(dòng)干預(yù)更少。

總的來說，F(xiàn)lannel是大多數(shù)用戶的不錯(cuò)選擇。從管理角度來看，它提供了一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)模型，用戶只需要一些基礎(chǔ)知識(shí)，就可以設(shè)置適合大多數(shù)用例的環(huán)境。一般來說，在初期使用Flannel是一個(gè)穩(wěn)妥安全的選擇，直到你開始需要一些它無法提供的東西。

Calico

鏈接：https://github.com/projectcalico/cni-plugin

Calico是Kubernetes生態(tài)系統(tǒng)中另一種流行的網(wǎng)絡(luò)選擇。雖然Flannel被公認(rèn)為是最簡(jiǎn)單的選擇，但Calico以其性能、靈活性而聞名。Calico的功能更為全面，不僅提供主機(jī)和pod之間的網(wǎng)絡(luò)連接，還涉及網(wǎng)絡(luò)安全和管理。Calico CNI插件在CNI框架內(nèi)封裝了Calico的功能。

在滿足系統(tǒng)要求的新配置的Kubernetes集群上，用戶可以通過應(yīng)用單個(gè)manifest文件快速部署Calico。如果您對(duì)Calico的可選網(wǎng)絡(luò)策略功能感興趣，可以向集群應(yīng)用其他manifest，來啟用這些功能。

盡管部署Calico所需的操作看起來相當(dāng)簡(jiǎn)單，但它創(chuàng)建的網(wǎng)絡(luò)環(huán)境同時(shí)具有簡(jiǎn)單和復(fù)雜的屬性。與Flannel不同，Calico不使用overlay網(wǎng)絡(luò)。相反，Calico配置第3層網(wǎng)絡(luò)，該網(wǎng)絡(luò)使用BGP路由協(xié)議在主機(jī)之間路由數(shù)據(jù)包。這意味著在主機(jī)之間移動(dòng)時(shí)，不需要將數(shù)據(jù)包包裝在額外的封裝層中。BGP路由機(jī)制可以本地引導(dǎo)數(shù)據(jù)包，而無需額外在流量層中打包流量。

除了性能優(yōu)勢(shì)之外，在出現(xiàn)網(wǎng)絡(luò)問題時(shí)，用戶還可以用更常規(guī)的方法進(jìn)行故障排除。雖然使用VXLAN等技術(shù)進(jìn)行封裝也是一個(gè)不錯(cuò)的解決方案，但該過程處理數(shù)據(jù)包的方式同場(chǎng)難以追蹤。使用Calico，標(biāo)準(zhǔn)調(diào)試工具可以訪問與簡(jiǎn)單環(huán)境中相同的信息，從而使更多開發(fā)人員和管理員更容易理解行為。

除了網(wǎng)絡(luò)連接外，Calico還以其先進(jìn)的網(wǎng)絡(luò)功能而聞名。 網(wǎng)絡(luò)策略是其最受追捧的功能之一。此外，Calico還可以與服務(wù)網(wǎng)格Istio集成，以便在服務(wù)網(wǎng)格層和網(wǎng)絡(luò)基礎(chǔ)架構(gòu)層中解釋和實(shí)施集群內(nèi)工作負(fù)載的策略。這意味著用戶可以配置強(qiáng)大的規(guī)則，描述Pod應(yīng)如何發(fā)送和接受流量，提高安全性并控制網(wǎng)絡(luò)環(huán)境。

如果對(duì)你的環(huán)境而言，支持網(wǎng)絡(luò)策略是非常重要的一點(diǎn)，而且你對(duì)其他性能和功能也有需求，那么Calico會(huì)是一個(gè)理想的選擇。此外，如果您現(xiàn)在或未來有可能希望得到技術(shù)支持，那么Calico是提供商業(yè)支持的。一般來說，當(dāng)您希望能夠長(zhǎng)期控制網(wǎng)絡(luò)，而不是僅僅配置一次并忘記它時(shí)，Calico是一個(gè)很好的選擇。

Weave

鏈接：https://www.weave.works/oss/net/

Weave是由Weaveworks提供的一種Kubernetes CNI網(wǎng)絡(luò)選項(xiàng)，它提供的模式和我們目前為止討論的所有網(wǎng)絡(luò)方案都不同。Weave在集群中的每個(gè)節(jié)點(diǎn)之間創(chuàng)建網(wǎng)狀Overlay網(wǎng)絡(luò)，參與者之間可以靈活路由。這一特性再結(jié)合其他一些獨(dú)特的功能，在某些可能導(dǎo)致問題的情況下，Weave可以智能地路由。

為了創(chuàng)建網(wǎng)絡(luò)，Weave依賴于網(wǎng)絡(luò)中每臺(tái)主機(jī)上安裝的路由組件。然后，這些路由器交換拓?fù)湫畔ⅲ跃S護(hù)可用網(wǎng)絡(luò)環(huán)境的***視圖。當(dāng)需要將流量發(fā)送到位于不同節(jié)點(diǎn)上的Pod時(shí)，Weave路由組件會(huì)自動(dòng)決定是通過“快速數(shù)據(jù)路徑”發(fā)送，還是回退到“sleeve”分組轉(zhuǎn)發(fā)的方法。

快速數(shù)據(jù)路徑依靠?jī)?nèi)核的本機(jī)Open vSwitch數(shù)據(jù)路徑模塊，將數(shù)據(jù)包轉(zhuǎn)發(fā)到適當(dāng)?shù)腜od，而無需多次移入和移出用戶空間。Weave路由器會(huì)更新Open vSwitch配置，以確保內(nèi)核層具有有關(guān)如何路由傳入數(shù)據(jù)包的準(zhǔn)確信息。相反，當(dāng)網(wǎng)絡(luò)拓?fù)洳贿m合快速數(shù)據(jù)路徑路由時(shí)，sleeve模式可用作備份。它是一種較慢的封裝模式，在快速數(shù)據(jù)路徑缺少必要的路由信息或連接的情況下，它可以來路由數(shù)據(jù)包。當(dāng)流量通過路由器時(shí)，它們會(huì)了解哪些對(duì)等體與哪些MAC地址相關(guān)聯(lián)，從而允許它們以更少的跳數(shù)、更智能地路由后續(xù)流量。當(dāng)網(wǎng)絡(luò)更改導(dǎo)致可用路由改變時(shí)，這一相同的機(jī)制可以幫助每個(gè)節(jié)點(diǎn)進(jìn)行自行更正。

與Calico一樣，Weave也為Kubernetes集群提供網(wǎng)絡(luò)策略功能。設(shè)置Weave時(shí)，網(wǎng)絡(luò)策略會(huì)自動(dòng)安裝和配置，因此除了添加網(wǎng)絡(luò)規(guī)則之外，用戶無需進(jìn)行其他配置。一個(gè)其他網(wǎng)絡(luò)方案都沒有、Weave獨(dú)有的功能，是對(duì)整個(gè)網(wǎng)絡(luò)的簡(jiǎn)單加密。雖然這會(huì)增加相當(dāng)多的網(wǎng)絡(luò)開銷，但Weave可以使用NaCl加密來為sleeve流量自動(dòng)加密所有路由流量，而對(duì)于快速數(shù)據(jù)路徑流量，因?yàn)樗枰用軆?nèi)核中的VXLAN流量，Weave會(huì)使用IPsec ESP來加密快速數(shù)據(jù)路徑流量。

對(duì)于那些尋求功能豐富的網(wǎng)絡(luò)、同時(shí)希望不要增加大量復(fù)雜性或管理難度的人來說，Weave是一個(gè)很好的選擇。它設(shè)置起來相對(duì)容易，提供了許多內(nèi)置和自動(dòng)配置的功能，并且可以在其他解決方案可能出現(xiàn)故障的場(chǎng)景下提供智能路由。網(wǎng)狀拓?fù)浣Y(jié)構(gòu)確實(shí)會(huì)限制可以合理容納的網(wǎng)絡(luò)的大小，不過對(duì)于大多數(shù)用戶來說，這也不是一個(gè)大問題。此外，Weave也提供收費(fèi)的技術(shù)支持，可以為企業(yè)用戶提供故障排除等等技術(shù)服務(wù)。

結(jié)語

Kubernetes采用的CNI標(biāo)準(zhǔn)，讓Kubernetes生態(tài)系統(tǒng)中的網(wǎng)絡(luò)解決方案百花齊放。更多樣的選擇，意味著大多數(shù)用戶將能夠找到適合其當(dāng)前需求和部署環(huán)境的CNI插件，同時(shí)還可以在環(huán)境發(fā)生變化時(shí)也能找到新的解決方案。

不同企業(yè)之間的運(yùn)營(yíng)要求差異很大，因此擁有一系列具有不同復(fù)雜程度和功能豐富性的成熟解決方案，大大有助于Kubernetes在滿足不同用戶獨(dú)特需求的前提下，仍然能夠提供一致的用戶體驗(yàn)。