Kubernetes CNI網絡最強對比：Flannel、Calico、Canal和Weave

介  紹

網絡架構是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在滿足不同使用者獨特需求的前提下，仍然能夠提供一緻的使用者體驗。