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

本文將在介紹技術原理和相應術語的基礎上，再集中探索與詳細對比目前最流行的CNI插件：Flannel、Calico、Weave和Canal，對比介紹它們的原理、使用方法、適用場景和優缺點等。

---

介 紹

網絡架構是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層鏈接之上的主機之間路由數據包。IPv四、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在知足不一樣用戶獨特需求的前提下，仍然可以提供一致的用戶體驗。