理解了 k8s 底層網絡模型和技術，對設計容器服務網絡拓撲會很有幫助，本文介紹了 k8s 網絡技術。

如果大家已經使用了 kubernetes技術，并運行了一些測試或生產的服務，可能已經能體會到 K8s 技術帶來的革命性變化，如果還沒有用過的小伙伴，我建議盡快入坑，畢竟這是技術趨勢。

目前盡管已經有很多工具可以用來設置和管理集群，但我們仍然需要知道在k8s底層發生了什么，尤其在碰到問題時，只有知道到底層原理才有可能從某個現象去分析到底是哪里出了問題，才能去解決實際問題。

從技術上說 Kubernetes 其實在底層它是非常復雜的，它有很多組件，因此，必須了解它們如何相互配合并協同工作，才能實際去理解實際中的問題，那說到這里，不得不說K8s的網絡是最復雜且最關鍵之一。

因此，這篇我們通過圖文來深入理解 Kubernetes 中的網絡如何工作。

Kubernetes Networking 的核心是一種重要的基本設計理念：

每一個Pod都有唯一的ip

此 Pod IP 由該Pod中的所有容器共享，并且可以與所有其他Pod路由。你是否曾經注意到Kubernetes節點上運行著一些“暫停”容器？它們被稱為“沙盒容器”，其唯一的工作就是保留和保存由Pod中的所有容器共享的網絡名稱空間（netns）。這樣，即使容器死亡，并且在其位置創建了一個新容器，容器IP也不會改變。這種按單機IP模式的巨大好處是與基礎主機之間沒有IP或端口沖突。而且，我們不必擔心應用程序使用哪個端口。

有了這個，Kubernetes 唯一的要求就是，這些Pod IP可以從其他所有Pod進行路由/訪問，而不管它們位于哪個節點上。

第一步是確保同一節點上的Pod能夠互相通信。然后將該思想擴展到跨節點，到Internet等的通信。

在每個Kubernetes節點（在本例中為Linux機器）上，都有一個根網絡名稱空間（根為基礎，而不是超級用戶）-root netns。

主網絡接口eth0在此根netns中。

同樣，每個Pod都有其自己的網絡，并且有一個虛擬以太網對將其連接到根網絡。這基本上是一個管道對，一端在根網中，另一端在pod網中。

我們將Pod-end命名為eth0，因此Pod不了解底層主機，并認為它具有自己的根網絡設置。另一端的名稱類似于vethxxx。

可以使用ifconfig或ip a命令在節點上列出所有這些接口。

對節點上的所有Pod完成此操作。為了使這些Pod相互通信，使用了Linux以太網橋cbr0。Docker使用了一個類似的橋，名為docker0。

可以使用brctl show命令列出網橋。

假設一個數據包從pod1到pod2。

1. 它將pod1的網絡保留在eth0處，并將根網絡保留在vethxxx。
2. 將其傳遞給cbr0，后者使用ARP請求發現目的地，并說“誰擁有此IP？”
3. vethyyy說它具有該IP，因此網橋知道將數據包轉發到何處。
4. 數據包到達vethyyy，穿過管道對并到達pod2的網絡。

這就是節點上的容器相互通信的方式。顯然還有其他方法，但這可能是最簡單的方法.

正如之前提到的，pod也必須在節點之間可訪問。Kubernetes并不關心它是如何完成的。我們可以使用L2（跨節點的ARP），L3（跨節點的IP路由-如云提供商路由表）覆蓋網絡。只要流量可以到達另一個節點上所需的Pod，這都沒有關系。每個節點都為Pod IP分配了唯一的CIDR塊（一系列IP地址），因此每個Pod具有一個唯一的IP，該IP與另一個節點上的Pod不沖突。

在大多數情況下，尤其是在云環境中，云提供商路由表可確保數據包到達正確的目的地。通過在每個節點上設置正確的路由，可以完成同一件事。還有許多其他的網絡插件也可以發揮自己的作用。

在這里，我們有兩個節點，類似于我們之前看到的。每個節點都有各種網絡名稱空間，網絡接口和網橋。