拿什麼拯救你 Kubernetes網絡之殇

曆史經驗告訴我們，網絡永遠是最後的難題——從大型機到虛拟機，再到現在的容器，而所有這些小實體都必須互相通信。

在過去30年的大部分時間裡，我們通過以太網實作了這種通信，其中應用層的不同通信端使用IP位址和端口号互相綁定。但是，當這些計算部分縮小到容器大小時，這是否還有意義呢？

如果兩個容器位于同一個實體機上，在相同的虛拟機管理程式上，在同一個Docker執行個體上，你是否真的需要一直跳到NIC以便于它們之間的通信？應用層尋址是否保持不變？使用overlay來促進這種通信會更好嗎？你是用L2還是L3？那麼多租戶呢？

所有這些問題都說明Kubernetes網絡是難題。   

Kubernetes網絡基礎知識

在了解Kubernetes基礎知識之前，了解Kubernetes所克服的Docker網絡局限性非常有用。這并不是說Docker網絡本質上是“邪惡”的，隻是容器引擎的範圍往往是單個實體機或虛拟機，是以當考慮一系列容器引擎時，自然會出現問題。

Docker model預設情況下使用主機—私有網絡，建立一個虛拟網橋和一系列映射，以便容器在同一台機器上對話。但是，不同機器上的容器需要端口配置設定和轉發或代理以便互相通信。

随着應用程式的規模不斷擴大，并且利用基于微服務的應用程式體系結構，這種體系結構需要許多容器（如果不是數百個容器分布在多台機器上），伸縮性就不盡如人意了。而且，這個網絡方案是為了在單台機器上運作而出現的，它确實支援CNM模型，可以實作多主機網絡，但考慮到它的初衷，它不适合叢集。

“Kubernetes model”不僅要解決核心叢集問題，而且還要允許針對不同情況有多種實作并後向相容單節點。這種模式的基本原理是所有的容器和節點都可以在沒有NAT的情況下互相通信，一個容器看到的自己的IP位址與别的容器或節點看到的相同。

Kubernetes術語中關于pod的基本定義是：它是“一組具有共享存儲/網絡的一個或多個容器，以及如何運作容器的規範”。

是以，位于同一個pod中的容器共享相同的IP和端口空間，并且可以使用本地主機彼此通路。這滿足了單容器引擎的後向相容性設計目标。

然而，更常見的是，應用程式中的微服務運作在不同的pod中，是以它們必須以更複雜的方式發現并通路彼此，而不是簡單地使用本地主機。這種機制在Kubernetes中被抽象出來，有多種實作方法——最流行的是使用overlay、underlay或native L3。

overlay方法使用的是與底層實體網絡去耦的虛拟網絡。這個虛拟網絡上的pod可以很容易地找到彼此，這些L2網絡可以彼此隔離，必要時需要它們之間的L3路由。

underlay方法将L2網絡連接配接到節點的實體NIC，進而将該pod直接暴露給底層實體網絡而無需端口映射。在這裡可以使用橋接模式來使pod能夠在内部進行互連，以便流量在不是必要時不會離開主機。

native L3方法在資料平面上不包含overlay，這意味着利用節點主機和外部網絡路由器做出路由決策，pod-to-pod的通信發生在IP位址上。pod-to-pod的通信可以利用BGP peering來不離開主機，如果需要的話，NAT可以用于輸出流量。

應用程式的需求和規模（包括可能需要在叢集外使用的其他資源）将決定哪種網絡方法适合你，并且每種方法都有各種開源和商業實施方案。

但Kubernetes不是在“真空”中運作

Kubernetes叢集很少在純粹的建立環境中部署。相反，它被部署用于支援業務線開發團隊的快速疊代工作，以便将創新注入到現有服務中。

舉個例子，在選擇overlay方法時，虛拟機主機上的容器需要與實體網絡中其他位置的服務進行通信，現在它要跳過多個層，每層都可能帶入不同數量的、可能會降低性能的延遲。因為這些基于微服務的應用程式并不常在”真空”中運作，是以在選擇方法和實施時需要仔細考慮，并且在同一組托管應用程式中為一個應用程式所做的選擇可能與另一個應用程式不同。

為什麼基于政策的Kubernetes網絡管理很有意義？

開發人員喜歡微服務，因為它使他們能夠建構具有更小的、更隔離的元件的解決方案，這些元件可以通過API對話。隻要這些API沒有改變，它們就充當元件之間的”契約”，而且這些元件可以彼此獨立地部署，使釋出更容易、更快。

但正如所有其他底層基礎設施的管理一樣，複雜性的增加會造成管理難題。你的叢集應該有多少個節點？當你後來改變主意時會發生什麼？如何管理因為運作的多個應用程式有不同的需求而一個叢集使用overlay網絡，另一個使用native L3的情況？你采取了哪些管理措施來保持一緻性和安全性？

這些問題擺在了管理Kubernetes叢集的團隊面前，而答案與解決其他基礎架構管理難題的一樣：政策。

管理者在管理軟體定義網絡和其上的虛拟機時發現，手動管理的“東西”的數量在某些時候難以繼續增加。Kubernetes叢集管理會使得，要管理的“東西”的數量大幅增加，并且在這個新的容器叢集中人工幹預不可持續。通過基于政策的管理實作自動化管理并實施最佳實踐，成為一個明确的選擇，無論單個應用程式的具體Kubernetes網絡方法是什麼。 是以，你可能正在管理越來越多的基于微服務的應用程式，無論這些應用程式是需要overlay、underlay或native L3網絡，請確定你選擇的任何實施方案都提供了通過使用合适插件的政策管理Kubernetes叢集網絡的選擇。否則，在叢集中實施變更并保持一緻性将很快變得不可能。但通過政策自動化管理意圖，你可以随時準備好滿足應用的需求。

本文轉移K8S技術社群-

拿什麼拯救你 Kubernetes網絡之殇