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

在過去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 GeekGathering杭州站最新活動打包資料，長按下方二維碼添加K8S技術社區小助手，備註「公司+從事領域」，社區小夥伴火速與你取得聯繫！

u.wechat.com/EJnxsZjUaf (二維碼自動識別)


推薦閱讀：
相關文章