如何實現Kubernetes CNI網絡的對比

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

介 紹

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

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

背 景

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

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

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

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

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

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

CNI的初衷是創建一個框架，用于在配置或銷毀容器時動態配置適當的網絡配置和資源。下面鏈接中的CNI規范概括了用于配制網絡的插件接口，這個接口可以讓容器運行時與插件進行協調：

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

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

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

在Kubernetes中，kubelet可以在適當的時間調用它找到的插件，來為通過kubelet啟動的pod進行自動的網絡配置。

術 語

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

一些最常見的術語包括：

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

• 第3層網絡： OSI網絡模型的“網絡”層。第3層網絡的主要關注點，是在第2層連接之上的主機之間路由數據包。IPv4、IPv6和ICMP是第3層網絡協議的示例。

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

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

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

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

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

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

CNI比較

Flannel

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

由CoreOS開發的項目Flannel，可能是最直接和最受歡迎的CNI插件。它是容器編排系統中最成熟的網絡結構示例之一，旨在實現更好的容器間和主機間網絡。隨著CNI概念的興起，Flannel CNI插件算是早期的入門。

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

Flannel配置第3層IPv4 overlay網絡。它會創建一個大型內部網絡，跨越集群中每個節點。在此overlay網絡中，每個節點都有一個子網，用于在內部分配IP地址。在配置pod時，每個節點上的Docker橋接口都會為每個新容器分配一個地址。同一主機中的Pod可以使用Docker橋接進行通信，而不同主機上的pod會使用flanneld將其流量封裝在UDP數據包中，以便路由到適當的目標。

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

總的來說，Flannel是大多數用戶的不錯選擇。從管理角度來看，它提供了一個簡單的網絡模型，用戶只需要一些基礎知識，就可以設置適合大多數用例的環境。一般來說，在初期使用Flannel是一個穩妥安全的選擇，直到你開始需要一些它無法提供的東西。

Calico

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

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

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

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

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

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

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

Canal

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

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

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

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

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

一般來說，如果你喜歡Flannel提供的網絡模型，但發現Calico的一些功能很誘人，那么不妨嘗試一下Canal。從安全角度來看，定義網絡策略規則的能力是一個巨大的優勢，并且在許多方面是Calico的殺手級功能。能夠將該技術應用到熟悉的網絡層，意味著您可以獲得更強大的環境，且可以省掉大部分的過渡過程。

Weave

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

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

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

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

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

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

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

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