原文發表於kubernetes中文社群，為作者原創翻譯 ，原文地址

更多kubernetes文章，請多關注kubernetes中文社群

目錄

CNI外掛的常見限制

1. 依賴軟體定義的網路(Software Defined Networking)

2. 在叢集外公開應用程式

3. 通過主機網路路由所有流量

4. 流量隔離

5. 負載不均衡

6. 額外 hops

7. 多宿主網路

8. 靜態端點配置

9. Noisy Neighbors 和SLA效能

10. 多區域支援

11. 儲存流量無分隔

另一種聯網方法Diamanti

---

雲原生應用程式的時代，引入了思考網路架構的新方法。

Kubernetes網路被設計為一種乾淨的，向後相容的模型，從而消除了將容器埠對映到主機埠的需求。為了支援這一點，Kubernetes引入了許多圍繞網路的基本結構，例如Pod網路，服務，叢集IP，容器埠，主機埠和節點埠，這些將使用者從底層基礎結構中解放出來。

儘管Kubernetes中有許多網路基礎的構建，但Kubernetes仍然存在許多故意的空白以使其與基礎架構無關。網路中的這些空白大部分由網路外掛填補，這些外掛通過容器網路介面（CNI）與Kubernetes互動。

CNI外掛的常見限制

Kubernetes使用外掛模型進行網路連線，使用CNI來管理叢集上的網路資源。大多數常見的CNI外掛利用overlay networking(覆蓋網路)，該網路在現有第2層（L2）網路之上在叢集內部建立了私有第3層（L3）網路。

使用這些CNI外掛，專用網路只能由叢集中的Pod訪問。在節點之間甚至在叢集外部交換資料包的過程在很大程度上取決於iptable規則以及專用和公用IP地址的網路地址轉換（NAT）。

這些CNI外掛的一些示例是Open vSwitch（OVS），Calico，Flannel，Canal和Weave。

每個可用於Kubernetes的網路CNI外掛都有其優缺點。讓我們探討一下CNI外掛的一些常見限制：

1. 依賴軟體定義的網路(Software Defined Networking)

SDN(Software Defined Networking)網路功能是作為軟體裝置提供的，從而增加了各種複雜性，包括其他iptables和NATing。

SDN軟體消耗了15％到20％的可用主機資源（CPU和記憶體），從而降低了效率並增加了執行實際應用程式所需的資源數量。

2. 在叢集外公開應用程式

由於大多數聯網解決方案都使用L3聯網，因此Pod IP的存在位於叢集本身內。將這些Pod暴露於外界仍然是一個挑戰。Kubernetes利用ServiceType中的“ NodePort”和“ LoadBalancers”公開應用程式。

ServiceType中的 NodePort通過在主機網路介面隨機唯一埠上，路由在節點上執行的所有應用程式。

在公共雲中，雲負載均衡器的可用性使生活變得更加輕鬆，因為它會自動將公共IP分配給Kubernetes中ServiceType為 LoadBalancer的服務。但是，此功能不適用於本地雲。諸如MetalLB之類的解決方案可以用來解決此問題，但是它們有其自身的侷限性和挑戰。

3. 通過主機網路路由所有流量

當使用用ServiceType中的“ NodePort”和“ LoadBalancers”時，Kubernetes利用主機網路介面路由所有流量。由於安全性和效能問題，這不是企業環境中的理想方案。

NodePort和Loadblancer服務的資料包流

4. 流量隔離

大多數Kubernetes網路解決方案都使用相同的物理網路（主機網路）介面來處理各種流量。

這意味著控制，pod和儲存流量共享同一網路介面。這可能會帶來安全風險，並且還會影響Kubernetes控制平面的效能，因為Pod和儲存流量很容易消耗可用頻寬（反之亦然）。

5. 負載不均衡

大多數網路解決方案都依賴於外部負載均衡器，當Pod分佈在叢集中的多個節點上時，這不是問題。

但是，同一後端服務的多個Pod也可以在同一節點上執行。這可能會導致負載不平衡問題，因為外部負載均衡器只能在節點之間進行負載均衡，而不能在Pod之間進行負載均衡。

6. 額外 hops

1）在資料包轉發網路中，hop指資料包經過路由器或直接通過節點轉移到其他網路的過程。在網際網路或者採用TCP/IP協議的網路中，hop數目會在資料包的包頭上面有所記錄。如果hop數目過大，就將此資料包忽略掉。

2）在蜂窩式數字分組資料（CDPD）中，hop是指到別的射頻通道的交換過程。

參考自：https://searchcio.techtarget.com.cn/whatis/8-24231/

在L3網路中，外部訪問總是通過暴露節點本身上的介面或埠來完成的。在這種情況下，如果請求通過錯誤的節點，則Pod和外部通訊可能會產生額外的hop，從而影響效能和延遲。

7. 多宿主網路

在許多情況下，該應用程式可能需要用於Pod網路的多個介面，以便它可以連線到不同的隔離網路/子網。目前，大多數CNI外掛均不支援多個介面。

8. 靜態端點配置

Kubernetes中的Pod IP是動態的，並且在Pod重新啟動時會更改。大多數CNI外掛不支援為Pod分配靜態端點或IP。

這意味著只能通過服務公開Pod，這對於某些型別的部署可能不是理想的選擇。

9. Noisy Neighbors 和SLA效能

在同一節點上執行多個應用程式時，來自每個應用程式的流量都流經同一網路管道。如果一個應用程式行為不正常，則可能會影響其他應用程式的效能。

大多數CNI外掛不支援在應用程式級別提供網路效能保證。

10. 多區域支援

高可用性對任何組織都至關重要，並且已成為生產Kubernetes部署中的要求。

擁有對多區域叢集的網路支援非常重要，該支援可將應用分佈在不同的域中。

11. 儲存流量無分隔

大多數CNI外掛無法區分儲存流量和常規流量。他們使用相同的共享介面來進行儲存資料交換，從而導致網路和儲存流量（在某些情況下甚至控制流量）相互競爭。這會影響效能和安全性。

另一種聯網方法Diamanti

Diamanti憑藉其獨特的網路體系結構解決了常見CNI外掛中發現的大多數缺點。

Diamanti的Kubernetes資料平面解決方案內建了對L2網路的支援，並且硬體解除安裝了智慧NIC。這允許將真正的L2 MAC地址分配給外部可路由網路上的每個Pod，從而使聯網更加容易。它還支援使用OVS的L3overlay networking(覆蓋網路)，流量隔離，VLAN/VXLAN分段，多宿主網路，靜態端點配置，網路感知排程，有保證的SLA以及許多其他獨特功能。

你可以在Diamanti網站上檢視有關Diamanti網路體系結構的更多詳細資訊。

Kubernetes中的網路堆疊是企業生產部署中最重要的架構決策之一。在為基礎架構選擇CNI外掛時，需要注意其侷限性，並確定最適合你的外掛。

譯文連結：https://thenewstack.io/top-considerations-when-selecting-cni-plugins-for-kubernetes/