如何實現(xiàn)Kubernetes CNI網(wǎng)絡的對比

如何實現(xiàn)Kubernetes CNI網(wǎng)絡的對比，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

介 紹

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

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

背 景

容器網(wǎng)絡是容器選擇連接到其他容器、主機和外部網(wǎng)絡（如Internet）的機制。容器的runtime提供了各種網(wǎng)絡模式，每種模式都會產(chǎn)生不同的體驗。例如，Docker默認情況下可以為容器配置以下網(wǎng)絡：

• none：將容器添加到一個容器專門的網(wǎng)絡堆棧中，沒有對外連接。

• host：將容器添加到主機的網(wǎng)絡堆棧中，沒有隔離。

• default bridge：默認網(wǎng)絡模式。每個容器可以通過IP地址相互連接。

• 自定義網(wǎng)橋：用戶定義的網(wǎng)橋，具有更多的靈活性、隔離性和其他便利功能。

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

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

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

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

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

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

術(shù) 語

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

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

• 第2層網(wǎng)絡： OSI（Open Systems Interconnections，開放系統(tǒng)互連）網(wǎng)絡模型的“數(shù)據(jù)鏈路”層。第2層網(wǎng)絡會處理網(wǎng)絡上兩個相鄰節(jié)點之間的幀傳遞。第2層網(wǎng)絡的一個值得注意的示例是以太網(wǎng)，其中MAC表示為子層。

• 第3層網(wǎng)絡： OSI網(wǎng)絡模型的“網(wǎng)絡”層。第3層網(wǎng)絡的主要關(guān)注點，是在第2層連接之上的主機之間路由數(shù)據(jù)包。IPv4、IPv6和ICMP是第3層網(wǎng)絡協(xié)議的示例。

• VXLAN：代表“虛擬可擴展LAN”。首先，VXLAN用于通過在UDP數(shù)據(jù)報中封裝第2層以太網(wǎng)幀來幫助實現(xiàn)大型云部署。VXLAN虛擬化與VLAN類似，但提供更大的靈活性和功能（VLAN僅限于4096個網(wǎng)絡ID）。VXLAN是一種封裝和覆蓋協(xié)議，可在現(xiàn)有網(wǎng)絡上運行。

• Overlay網(wǎng)絡：Overlay網(wǎng)絡是建立在現(xiàn)有網(wǎng)絡之上的虛擬邏輯網(wǎng)絡。Overlay網(wǎng)絡通常用于在現(xiàn)有網(wǎng)絡之上提供有用的抽象，并分離和保護不同的邏輯網(wǎng)絡。

• 封裝：封裝是指在附加層中封裝網(wǎng)絡數(shù)據(jù)包以提供其他上下文和信息的過程。在overlay網(wǎng)絡中，封裝被用于從虛擬網(wǎng)絡轉(zhuǎn)換到底層地址空間，從而能路由到不同的位置（數(shù)據(jù)包可以被解封裝，并繼續(xù)到其目的地）。

• 網(wǎng)狀網(wǎng)絡：網(wǎng)狀網(wǎng)絡（Mesh network）是指每個節(jié)點連接到許多其他節(jié)點以協(xié)作路由、并實現(xiàn)更大連接的網(wǎng)絡。網(wǎng)狀網(wǎng)絡允許通過多個路徑進行路由，從而提供更可靠的網(wǎng)絡。網(wǎng)狀網(wǎng)格的缺點是每個附加節(jié)點都會增加大量開銷。

• BGP：代表“邊界網(wǎng)關(guān)協(xié)議”，用于管理邊緣路由器之間數(shù)據(jù)包的路由方式。BGP通過考慮可用路徑，路由規(guī)則和特定網(wǎng)絡策略，幫助弄清楚如何將數(shù)據(jù)包從一個網(wǎng)絡發(fā)送到另一個網(wǎng)絡。BGP有時被用作CNI插件中的路由機制，而不是封裝的覆蓋網(wǎng)絡。

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

CNI比較

Flannel

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

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

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

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

Flannel有幾種不同類型的后端可用于封裝和路由。默認和推薦的方法是使用VXLAN，因為VXLAN性能更良好并且需要的手動干預更少。

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

Calico

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

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

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

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

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

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

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

Canal

鏈接：https://github.com/projectcalico/canal

Canal也是一個有趣的選擇，原因有很多。

首先，Canal 是一個項目的名稱，它試圖將Flannel提供的網(wǎng)絡層與Calico的網(wǎng)絡策略功能集成在一起。然而，當貢獻者完成細節(jié)工作時卻發(fā)現(xiàn)，很明顯，如果Flannel和Calico這兩個項目的標準化和靈活性都已各自確保了話，那集成也就沒那么大必要了。結(jié)果，這個官方項目變得有些“爛尾”了，不過卻實現(xiàn)了將兩種技術(shù)部署在一起的預期能力。出于這個原因，即使這個項目不復存在，業(yè)界還是會習慣性地將Flannel和Calico的組成稱為“Canal”。

由于Canal是Flannel和Calico的組合，因此它的優(yōu)點也在于這兩種技術(shù)的交叉。網(wǎng)絡層用的是Flannel提供的簡單overlay，可以在許多不同的部署環(huán)境中運行且無需額外的配置。在網(wǎng)絡策略方面，Calico強大的網(wǎng)絡規(guī)則評估，為基礎(chǔ)網(wǎng)絡提供了更多補充，從而提供了更多的安全性和控制。

確保集群滿足必要的系統(tǒng)要求（https://docs.projectcalico.org/v3.6/getting-started/kubernetes/requirements）后，用戶需要應用兩個manifest才能部署Canal，這使得其配置比單獨的任何一個項目都困難。如果企業(yè)的IT團隊計劃改變他們的網(wǎng)絡方案，且希望在實施改變之前能先對網(wǎng)絡策略進行一些實驗并獲取一些經(jīng)驗，那么Canal是一個不錯的選擇。

一般來說，如果你喜歡Flannel提供的網(wǎng)絡模型，但發(fā)現(xiàn)Calico的一些功能很誘人，那么不妨嘗試一下Canal。從安全角度來看，定義網(wǎng)絡策略規(guī)則的能力是一個巨大的優(yōu)勢，并且在許多方面是Calico的殺手級功能。能夠?qū)⒃摷夹g(shù)應用到熟悉的網(wǎng)絡層，意味著您可以獲得更強大的環(huán)境，且可以省掉大部分的過渡過程。

Weave

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

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

為了創(chuàng)建網(wǎng)絡，Weave依賴于網(wǎng)絡中每臺主機上安裝的路由組件。然后，這些路由器交換拓撲信息，以維護可用網(wǎng)絡環(huán)境的最新視圖。當需要將流量發(fā)送到位于不同節(jié)點上的pod時，Weave路由組件會自動決定是通過“快速數(shù)據(jù)路徑”發(fā)送，還是回退到“sleeve”分組轉(zhuǎn)發(fā)的方法。

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

與Calico一樣，Weave也為Kubernetes集群提供網(wǎng)絡策略功能。設(shè)置Weave時，網(wǎng)絡策略會自動安裝和配置，因此除了添加網(wǎng)絡規(guī)則之外，用戶無需進行其他配置。一個其他網(wǎng)絡方案都沒有、Weave獨有的功能，是對整個網(wǎng)絡的簡單加密。雖然這會增加相當多的網(wǎng)絡開銷，但Weave可以使用NaCl加密（http://nacl.cr.yp.to）來為sleeve流量自動加密所有路由流量，而對于快速數(shù)據(jù)路徑流量，因為它需要加密內(nèi)核中的VXLAN流量，Weave會使用IPsec ESP來加密快速數(shù)據(jù)路徑流量。

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

Kubernetes采用的CNI標準，讓Kubernetes生態(tài)系統(tǒng)中的網(wǎng)絡解決方案百花齊放。更多樣的選擇，意味著大多數(shù)用戶將能夠找到適合其當前需求和部署環(huán)境的CNI插件，同時還可以在環(huán)境發(fā)生變化時也能找到新的解決方案。不同企業(yè)之間的運營要求差異很大，因此擁有一系列具有不同復雜程度和功能豐富性的成熟解決方案，大大有助于Kubernetes在滿足不同用戶獨特需求的前提下，仍然能夠提供一致的用戶體驗。

看完上述內(nèi)容，你們掌握如何實現(xiàn)Kubernetes CNI網(wǎng)絡的對比的方法了嗎？如果還想學到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！