Kubernetes 是為運行分布式集群而建立的，分布式系統的本質使得網絡成為 Kubernetes 的核心和必要組成部分，了解 Kubernetes 網絡模型可以使你能夠正確運行、監控和排查應用程序故障。

網絡是非常復雜的，擁有許多概念，對于不熟悉這個領域的用戶來說，這可能會有一定的難度，這里面有很多概念需要理解，并且還需要把這些概念整合起來形成一個連貫的整體，比如網絡命名空間、虛擬接口、IP 轉發、NAT 等概念。

Kubernetes 中對任何網絡實現都規定了以下的一些要求：

• 所有 Pod 都可以在不使用 NAT 的情況下與所有其他 Pod 進行通信
• 所有節點都可以在沒有 NAT 的情況下與所有 Pod 進行通信
• Pod 自己的 IP 與其他 Pod 看到的 IP 是相同的

鑒于這些限制，我們需要解決幾個不同的網絡問題：

1. 容器到容器的網絡
2. Pod 到 Pod 的網絡
3. Pod 到 Service 的網絡
4. 互聯網到 Service 的網絡

接下來我們將來討論這些問題及其解決方案。

容器到容器網絡

通常情況下我們將虛擬機中的網絡通信視為直接與以太網設備進行交互，如圖1所示。

圖1.網絡設備的理想視圖

實際的情況肯定比這要復雜，在 Linux 中，每個正在運行的進程都在一個網絡命名空間內進行通信，該命名空間提供了一個具有自己的路由、防火墻規則和網絡設備的邏輯網絡棧，從本質上講，網絡命名空間為命名空間內的所有進程提供了一個全新的網絡堆棧。

Linux 用戶可以使用 ip 命令創建網絡命名空間。例如，以下命令將創建一個名為 ns1 的網絡命名空間。

$ipnetnsaddns1

命名空間創建后，會在 /var/run/netns 下面為其創建一個掛載點，即使沒有附加任何進程，命名空間也是可以保留的。

你可以通過列出 /var/run/netns 下的所有掛載點或使用 ip 命令來列出可用的命名空間。

$ls/var/run/netns
ns1
$ipnetns
ns1

默認情況下，Linux 將為每個進程分配到 root network namespace，以提供訪問外部的能力，如圖2所示。

圖2.root network namespace

對于 Docker 而言，一個 Pod 會被構建成一組共享網絡命名空間的 Docker 容器，Pod 中的容器都有相同的 IP 地址和端口空間，它們都是通過分配給 Pod 的網絡命名空間來分配的，并且可以通過 localhost 訪問彼此，因為它們位于同一個命名空間中。這是使用 Docker 作為 Pod 容器來實現的，它持有網絡命名空間，而應用容器則通過 Docker 的 -net=container:sandbox-container 功能加入到該命名空間中，圖3顯示了每個 Pod 如何由共享網絡命名空間內的多個 Docker 容器（ctr*）組成的。

圖3.每個 Pod 的網絡命名空間

此外 Pod 中的容器還可以訪問共享卷，這些卷被定義為 Pod 的一部分，并且可以掛載到每個容器的文件系統中。

Pod 到 Pod 網絡

在 Kubernetes 中，每個 Pod 都有一個真實的 IP 地址，每個 Pod 都使用該 IP 地址與其他 Pod 進行通信。接下來我們將來了解 Kubernetes 如何使用真實的 IP 來實現 Pod 與 Pod 之間的通信的。我們先來討論同一節點上的 Pod 通信的方式。

從 Pod 的角度來看，它存在于自己的網絡命名空間中，需要與同一節點上的其他網絡命名空間進行通信。值得慶幸的時候，命名空間可以使用 Linux 虛擬以太網設備或由兩個虛擬接口組成的 veth 對進行連接，這些虛擬接口可以分布在多個命名空間上。要連接 Pod 命名空間，我們可以將 veth 對的的一側分配給 root network namespace，將另一側分配給 Pod 的網絡命名空間。每個 veth 對就像一根網線，連接兩側并允許流量在它們之間流動。這種設置可以復制到節點上的任意數量的 Pod。圖4顯示了連接虛擬機上每個 Pod 的 root network namespace 的 veth 對。

圖4.Pod 的 veth 對

現在 Pod 都有自己的網絡命名空間，這樣它們就有自己的網絡設備和 IP 地址，并且它們連接到節點的 root 命名空間，現在我們希望 Pod 能夠通過 root 命名空間進行通信，那么我們將要使用一個網絡 bridge（網橋）來實現。

Linux bridge 是用純軟件實現的虛擬交換機，有著和物理交換機相同的功能，例如二層交換，MAC 地址學習等。因此我們可以把 veth pair 等設備綁定到網橋上，就像是把設備連接到物理交換機上一樣。bridge 的工作方式是通過檢查通過它的數據包目的地，并決定是否將數據包傳遞給連接到網橋的其他網段，從而在源和目的地之間維護一個轉發表。bridge 通過查看網絡中每個以太網設備的唯一 MAC 地址來決定是橋接數據還是丟棄數據。

Bridges 實現了 ARP 協議來發現與指定 IP 地址關聯的鏈路層 MAC 地址。當 bridge 接收到數據幀的時候，bridge 將該幀廣播給所有連接的設備（原始發送者除外），響應該幀的設備被存儲在一個查找表中，未來具有相同 IP 地址的通信使用查找表來發現正確的 MAC 地址來轉發數據包。

圖5.使用橋接連接命名空間

同節點 Pod 通信

網絡命名空間將每個 Pod 隔離到自己的網絡堆棧中，虛擬以太網設備將每個命名空間連接到根命名空間，以及一個將命名空間連接在一起的網橋，這樣我們就準備好在同一節點上的 Pod 之間發送流量了，如下圖6所示。

同節點上的Pod間的數據包移動

這上圖中，pod1 向自己的網絡設備 eth0 發送了一個數據包，對于 pod1 來說，eth0 通過虛擬網絡設備連接到 root netns 的 veth0(1)，網橋 cbr0 被配置為與 veth0 一端相連，一旦數據包到達網橋，網橋就會使用 ARP 協議將數據包發送到 veth1(3)。當數據包到達虛擬設備 veth1 時，它被直接轉發到 pod2 的命名空間內的 eth0(4) 設備。這整個過程中，每個 Pod 僅與 localhost 上的 eth0 進行通信，流量就會被路由到正確的 Pod。

Kubernetes 的網絡模型決定了 Pod 必須可以通過其 IP 地址跨節點訪問，也就是說，一個 Pod 的 IP 地址始終對網絡中的其他 Pod 是可見的，每個 Pod 看待自己的 IP 地址的方式與其他 Pod 看待它的方式是相同的。接下來我們來看看不同節點上的 Pod 之間的流量路由問題。

跨節點 Pod 通信

在研究了如何在同一節點上的 Pod 之間路由數據包之后，接下來我們來看下不同節點上的 Pod 之間的通信。Kubernetes 網絡模型要求 Pod 的 IP 是可以通過網絡訪問的，但它并沒有規定必須如何來實現。

通常集群中的每個節點都分配有一個 CIDR，用來指定該節點上運行的 Pod 可用的 IP 地址。一旦以 CIDR 為目的地的流量到達節點，節點就會將流量轉發到正確的 Pod。圖7展示了兩個節點之間的網絡通信，假設網絡可以將 CIDR 中的流量轉發到正確的節點。

圖7.不同節點上的Pod間通信

上圖一樣和圖6相同的地方開始請求，但是這次目標 Pod（綠色標注）與源 Pod（藍色標注）位于不同的節點上。數據包首先通過 pod1 的網絡設備發送，該設備與 root netns（1）中的虛擬網絡設備配對，最終數據包到達 root netns 的網橋（2）上。這個時候網橋上的 ARP 會失敗，因為與網橋相連的沒有正確的數據包 MAC 地址。一旦失敗，網橋會將數據包發送到默認路由上 - root netns 的 eth0 設備，此時就會路由離開節點，進入網絡（3）。我們現在假設網絡可以根據分配給節點的 CIDR 將數據包路由到正確的節點（4）。數據包進入目標節點的 root netns（VM2 上的 eth0），這那里它通過網橋路由到正確的虛擬設備（5）。最后，路由通過位于 pod4 的命名空間（6）中的虛擬設備 eth0 來完成。一般來說，每個節點都知道如何將數據包傳遞給其內部運行的 Pod，一旦數據包到達目標節點，數據包的流動方式與同一節點上的 Pod 間通信方式一樣。

我們這里沒有介紹如何配置網絡來將 Pod IPs 的流量路由到負責這些 IP 的正確節點，這和特定的網絡有關系，比如 AWS 就維護了一個 Kubernetes 容器網絡插件，該插件允許在 AWS 的 VPC 環境中使用 [容器網絡接口（CNI）插件]（https://github.com/aws/amazon-vpc-cni-k8s）來進行節點到節點的網絡通信。

在 EC2 中，每個實例都綁定到一個彈性網絡接口 (ENI)，并且所有 ENI 都連接在一個 VPC 內 —— ENI 無需額外操作即可相互訪問。默認情況下，每個 EC2 實例部署一個 ENI，但你可以創建多個 ENI 并將它們部署到 EC2 實例上。Kubernetes 的 AWS CNI 插件會為節點上的每個 Pod 創建一個新的 ENI，因為 VPC 中的 ENI 已經連接到了現有 AWS 基礎設施中，這使得每個 Pod 的 IP 地址可以在 VPC 內自然尋址。當 CNI 插件被部署到集群時，每個節點（EC2 實例）都會創建多個彈性網絡接口，并為這些實例分配 IP 地址，從而為每個節點形成了一個 CIDR 塊。當部署 Pod 時，有一個小的二進制文件會作為 DaemonSet 部署到 Kubernetes 集群中，從節點本地的 kubelet 進程接收任何添加 Pod 到網絡的請求，這個二進制文件會從節點的可用 ENI 池中挑選一個可用的 IP 地址，并通過在 Linux 內核中連接虛擬網絡設備和網橋將其分配給 Pod，和在同一節點內容的 Pod 通信一樣，有了這個，Pod 的流量就可以跨集群內的節點進行通信了。

Pod 到 Service

上面我們已經介紹了如何在 Pod 和它們相關的 IP 地址之間的通信。但是 Pod 的 IP 地址并不是固定不變的，會隨著應用的擴縮容、應用崩潰或節點重啟而出現或消失，這些都可能導致 Pod IP 地址發生變化，Kubernetes 中可以通過 Service 對象來解決這個問題。

Kubernetes Service 管理一組 Pod，允許你跟蹤一組隨時間動態變化的 Pod IP 地址，Service 作為對 Pod 的抽象，為一組 Pod 分配一個虛擬的 VIP 地址，任何發往 Service VIP 的流量都會被路由到與其關聯的一組 Pod。這就允許與 Service 相關的 Pod 集可以隨時變更 - 客戶端只需要知道 Service VIP 即可。

創建 Service 時候，會創建一個新的虛擬 IP（也稱為 clusterIP），這集群中的任何地方，發往虛擬 IP 的流量都將負載均衡到與 Service 關聯的一組 Pod。實際上，Kubernetes 會自動創建并維護一個分布式集群內的負載均衡器，將流量分配到 Service 相關聯的健康 Pod 上。接下來讓我們仔細看看它是如何工作的。

netfilter 與 iptables

為了在集群中執行負載均衡，Kubernetes 會依賴于 Linux 內置的網絡框架 - netfilter。Netfilter 是 Linux 提供的一個框架，它允許以自定義處理程序的形式實現各種與網絡相關的操作，Netfilter 為數據包過濾、網絡地址轉換和端口轉換提供了各種功能和操作，它們提供了引導數據包通過網絡所需的功能，以及提供禁止數據包到達計算機網絡中敏感位置的能力。

iptables 是一個用戶空間程序，它提供了一個基于 table 的系統，用于定義使用 netfilter 框架操作和轉換數據包的規則。在 Kubernetes 中，iptables 規則由 kube-proxy 控制器配置，該控制器會 watch kube-apiserver 的變更，當對 Service 或 Pod 的變化更新了 Service 的虛擬 IP 地址或 Pod 的 IP 地址時，iptables 規則會被自動更新，以便正確地將指向 Service 的流量路由到支持 Pod。iptables 規則會監聽發往 Service VIP 的流量，并且在匹配時，從可用 Pod 集中選擇一個隨機 Pod IP 地址，并且 iptables 規則將數據包的目標 IP 地址從 Service 的 VIP 更改為所選的 Pod IP。當 Pod 啟動或關閉時，iptables 規則集也會更新以反映集群的變化狀態。換句話說，iptables 已經在節點上做了負載均衡，以將指向 Service VIP 的流量路由到實際的 Pod 的 IP 上。

在返回路徑上，IP 地址來自目標 Pod，在這種情況下，iptables 再次重寫 IP 頭以將 Pod IP 替換為 Service 的 IP，以便 Pod 認為它一直只與 Service 的 IP 通信。

IPVS

Kubernetes 新版本已經提供了另外一個用于集群負載均衡的選項：IPVS， IPVS 也是構建在 netfilter 之上的，并作為 Linux 內核的一部分實現了傳輸層的負載均衡。IPVS 被合并到了 LVS（Linux 虛擬服務器）中，它在主機上運行并充當真實服務器集群前面的負載均衡器，IPVS 可以將基于 TCP 和 UDP 的服務請求定向到真實服務器，并使真實服務器的服務作為虛擬服務出現在一個 IP 地址上。這使得 IPVS 非常適合 Kubernetes 服務。

這部署 kube-proxy 時，可以指定使用 iptables 或 IPVS 來實現集群內的負載均衡。IPVS 專為負載均衡而設計，并使用更高效的數據結構（哈希表），與 iptables 相比允許更大的規模。在使用 IPVS 模式的 Service 時，會發生三件事：在 Node 節點上創建一個虛擬 IPVS 接口，將 Service 的 VIP 地址綁定到虛擬 IPVS 接口，并為每個 Service VIP 地址創建 IPVS 服務器。

Pod 到 Service 通信

圖8. Pod 與 Service 之間通信

當這 Pod 和 Service 之間路由一個數據包時，流量和以前開始的方式一樣，數據包首先通過連接到 Pod 的網絡命名空間（1）的 eth0 離開 Pod，。然后它通過虛擬網絡設備到達網橋（2）。網橋上運行的 ARP 是不知道 Service 地址的，所以它通過默認路由 eth0（3）將數據包傳輸出去。到這里會有一些不同的地方了，在 eth0 接收之前，該數據包會被 iptables 過濾，在收到數據包后，iptables 使用 kube-proxy 在節點上安裝的規則來響應 Service 或 Pod 事件，將數據包的目的地從 Service VIP 改寫為特定的 Pod IP（4）。該數據包現在就要到達 pod4 了，而不是 Service 的 VIP，iptables 利用內核的 conntrack 工具來記錄選擇的 Pod，以便將來的流量會被路由到相同的 Pod。從本質上講，iptables 直接從節點上完成了集群內的負載均衡，然后流量流向 Pod，剩下的就和前面的 Pod 到 Pod 通信一樣的了（5）。

Service 到 Pod 通信

圖9.在 Service 和 Pod 之間通信

相應的回包的時候，收到該數據包的 Pod 將響應，將源 IP 標記為自己的 IP，將目標 IP 標記為最初發送數據包的 Pod(1)。進入節點后，數據包流經 iptables，它使用 conntrack 記住它之前所做的選擇，并將數據包的源重寫為 Service 的 VIP 而不是現在 Pod 的 IP(2)。從這里開始，數據包通過網橋流向與 Pod 的命名空間配對的虛擬網絡設備 (3)，然后流向我們之前看到的 Pod 的虛擬網絡設備 (4)。

外網到 Service 通信

到這里我們已經了解了 Kubernetes 集群內的流量是如何路由的，但是更多的時候我們需要將服務暴露到外部去。這個時候會涉及到兩個主要的問題：

• 將流量從 Kubernetes 服務路由到互聯網上去
• 將流量從互聯網傳到你的 Kubernetes 服務

接下來我們就來討論這些問題。

出流量

從節點到公共 Internet 的路由流量也是和特定的網絡有關系的，這取決于你的網絡如何配置來發布流量的。這里我們以 AWS VPC 為例來進行說明。

在 AWS 中，Kubernetes 集群在 VPC 中運行，每個節點都分配有一個私有 IP 地址，該地址可從 Kubernetes 集群內訪問。要從集群外部訪問服務，你可以在 VPC 上附加一個外網網關。外網網關有兩個用途：在你的 VPC 路由表中為可路由到外網的流量提供目標，以及為已分配公共 IP 地址的實例執行網絡地址轉換 (NAT)。NAT 轉換負責將集群節點的內部 IP 地址更改為公網中可用的外部 IP 地址。

有了外網網關，VM 就可以自由地將流量路由到外網。不過有一個小問題，Pod 有自己的 IP 地址，與運行 Pod 的節點 IP 地址不同，并且外網網關的 NAT 轉換僅適用于 VM IP 地址，因為它不知道哪些 Pod 在哪些 VM 上運行 —— 網關不支持容器。讓我們看看 Kubernetes 是如何使用 iptables 來解決這個問題的。

在下圖中，數據包源自 Pod 的命名空間 (1)，并經過連接到根命名空間 (2) 的 veth 對。一旦進入根命名空間，數據包就會從網橋移動到默認設備，因為數據包上的 IP 與連接到網橋的任何網段都不匹配。在到達根命名空間的網絡設備 (3) 之前，iptables 會破壞數據包 (3)。在這種情況下，數據包的源 IP 地址是 Pod，如果我們將源保留為 Pod，外網網關將拒絕它，因為網關 NAT 只了解連接到 VM 的 IP 地址。解決方案是讓 iptables 執行源 NAT —— 更改數據包源，使數據包看起來來自 VM 而不是 Pod。有了正確的源 IP，數據包現在可以離開 VM (4) 并到達外網網關 (5) 了。外網網關將執行另一個 NAT，將源 IP 從 VM 內部 IP 重寫為公網IP。最后，數據包將到達互聯網上 (6)。在返回的路上，數據包遵循相同的路徑，并且任何源 IP 的修改都會被取消，這樣系統的每一層都會接收到它理解的 IP 地址：節點或 VM 級別的 VM 內部，以及 Pod 內的 Pod IP命名空間。

圖10.從Pod到互聯網通信

入流量

讓流量進入你的集群是一個非常難以解決的問題。同樣這也和特定的網絡環境有關系，但是一般來說入流量可以分為兩種解決方案：

• Service LoadBalancer
• Ingress 控制器

LoadBalancer

當你創建一個 Kubernetes Service時，你可以選擇指定一個 LoadBalancer 來使用它。LoadBalancer 有為你提供服務的云供應商負責創建負載均衡器，創建服務后，它將暴露負載均衡器的 IP 地址。終端用戶可以直接通過該 IP 地址與你的服務進行通信。

LoadBalancer 到 Service

在部署了 Service 后，你使用的云提供商將會為你創建一個新的 LoadBalancer（1）。因為 LoadBalancer 不支持容器，所以一旦流量到達 LoadBalancer，它就會分布在集群的各個節點上（2）。每個節點上的 iptables 規則會將來自 LoadBalancer 的傳入流量路由到正確的 Pod 上（3）。從 Pod 到客戶端的響應將返回 Pod 的 IP，但客戶端需要有 LoadBalancer 的 IP 地址。正如我們之前看到的，iptables 和 conntrack 被用來在返回路徑上正確重寫 IP 地址。

下圖展示的就是托管 Pod 的三個節點前面的負載均衡器。傳入流量（1）指向 Service 的 LoadBalancer，一旦 LoadBalancer 接收到數據包（2），它就會隨機選擇一個節點。我們這里的示例中，我們選擇了沒有運行 Pod 的節點 VM2（3）。在這里，運行在節點上的 iptables 規則將使用 kube-proxy 安裝到集群中的內部負載均衡規則，將數據包轉發到正確的 Pod。iptables 執行正確的 NAT 并將數據包轉發到正確的 Pod（4）。

圖11.外網訪問 Service

Ingress 控制器

在七層網絡上 Ingress 在 HTTP/HTTPS 協議范圍內運行，并建立在 Service 之上。啟用 Ingress 的第一步是使用 Kubernetes 中的 NodePort 類型的 Service，如果你將 Service 設置成 NodePort 類型，Kubernetes master 將從你指定的范圍內分配一個端口，并且每個節點都會將該端口代理到你的 Service，也就是說，任何指向節點端口的流量都將使用 iptables 規則轉發到 Service。

將節點的端口暴露在外網，可以使用一個 Ingress 對象，Ingress 是一個更高級別的 HTTP 負載均衡器，它將 HTTP 請求映射到 Kubernetes Service。根據控制器的實現方式，Ingress 的使用方式會有所不同。HTTP 負載均衡器，和四層網絡負載均衡器一樣，只了解節點 IP（而不是 Pod IP），因此流量路由同樣利用由 kube-proxy 安裝在每個節點上的 iptables 規則提供的內部負載均衡。

在 AWS 環境中，ALB Ingress 控制器使用 AWS 的七層應用程序負載均衡器提供 Kubernetes 入口。下圖詳細介紹了此控制器創建的 AWS 組件，它還演示了 Ingress 流量從 ALB 到 Kubernetes 集群的路由。

圖12.Ingress 控制器

創建后，(1) Ingress Controller 會 watch 來自 Kubernetes APIServer 的 Ingress 事件。當它找到滿足其要求的 Ingress 資源時，它會開始創建 AWS 資源。AWS 將 Application Load Balancer (ALB) (2) 用于 Ingress 資源。負載均衡器與用于將請求路由到一個或多個注冊節點的 TargetGroup一起工作。(3) 在 AWS 中為 Ingress 資源描述的每個唯一 Kubernetes Service 創建 TargetGroup。(4) Listener 是一個 ALB 進程，它使用你配置的協議和端口檢查連接請求。Listener 由 Ingress 控制器為你的 Ingress 資源中描述的每個端口創建。最后，為 Ingress 資源中指定的每個路徑創建 TargetGroup 規則。這可以保證到特定路徑的流量被路由到正確的 Kubernetes 服務上 (5)。

Ingress 到 Service

流經 Ingress 的數據包的生命周期與 LoadBalancer 的生命周期非常相似。主要區別在于 Ingress 知道 URL 的路徑（可以根據路徑將流量路由到 Service）Ingress 和節點之間的初始連接是通過節點上為每個服務暴露的端口。

部署 Service 后，你使用的云提供商將為你創建一個新的 Ingress 負載均衡器 (1)。因為負載均衡器不支持容器，一旦流量到達負載均衡器，它就會通過為你的服務端口分布在組成集群 (2) 的整個節點中。每個節點上的 iptables 規則會將來自負載均衡器的傳入流量路由到正確的 Pod (3)。Pod 到客戶端的響應將返回 Pod 的 IP，但客戶端需要有負載均衡器的 IP 地址。正如我們之前看到的，iptables 和 conntrack 用于在返回路徑上正確重寫 IP。

圖13.從 Ingress 到 Service

總結

本文介紹了 Kubernetes 網絡模型以及如何實現常見網絡任務。網絡知識點既廣泛又很深，所以我們這里不可能涵蓋所有的內容，但是你可以以本文為起點，然后去深入了解你感興趣的主題。