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

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

Kubernetes 中對任何網(wǎng)絡實現(xiàn)都規(guī)定了以下的一些要求：

所有 Pod 都可以在不使用 NAT 的情況下與所有其他 Pod 進行通信

所有節(jié)點都可以在沒有 NAT 的情況下與所有 Pod 進行通信

Pod 自己的 IP 與其他 Pod 看到的 IP 是相同的

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

容器到容器的網(wǎng)絡

Pod 到 Pod 的網(wǎng)絡

Pod 到 Service 的網(wǎng)絡

互聯(lián)網(wǎng)到 Service 的網(wǎng)絡

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

容器到容器網(wǎng)絡

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

圖1.網(wǎng)絡設備的理想視圖

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

Linux 用戶可以使用ip命令創(chuàng)建網(wǎng)絡命名空間。例如，以下命令將創(chuàng)建一個名為 ns1 的網(wǎng)絡命名空間。

$ipnetnsaddns1

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

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

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

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

圖2.root network namespace

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

圖3.每個 Pod 的網(wǎng)絡命名空間

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

Pod 到 Pod 網(wǎng)絡

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

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

圖4.Pod 的 veth 對

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

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

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

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

同節(jié)點 Pod 通信

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

同節(jié)點上的Pod間的數(shù)據(jù)包移動

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

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

跨節(jié)點 Pod 通信

在研究了如何在同一節(jié)點上的 Pod 之間路由數(shù)據(jù)包之后，接下來我們來看下不同節(jié)點上的 Pod 之間的通信。Kubernetes 網(wǎng)絡模型要求 Pod 的 IP 是可以通過網(wǎng)絡訪問的，但它并沒有規(guī)定必須如何來實現(xiàn)。

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

圖7.不同節(jié)點上的Pod間通信

上圖一樣和圖6相同的地方開始請求，但是這次目標 Pod（綠色標注）與源 Pod（藍色標注）位于不同的節(jié)點上。數(shù)據(jù)包首先通過 pod1 的網(wǎng)絡設備發(fā)送，該設備與 root netns（1）中的虛擬網(wǎng)絡設備配對，最終數(shù)據(jù)包到達 root netns 的網(wǎng)橋（2）上。

這個時候網(wǎng)橋上的 ARP 會失敗，因為與網(wǎng)橋相連的沒有正確的數(shù)據(jù)包 MAC 地址。一旦失敗，網(wǎng)橋會將數(shù)據(jù)包發(fā)送到默認路由上 - root netns 的eth0設備，此時就會路由離開節(jié)點，進入網(wǎng)絡（3）。我們現(xiàn)在假設網(wǎng)絡可以根據(jù)分配給節(jié)點的CIDR將數(shù)據(jù)包路由到正確的節(jié)點（4）。數(shù)據(jù)包進入目標節(jié)點的 root netns（VM2 上的 eth0），這那里它通過網(wǎng)橋路由到正確的虛擬設備（5）。最后，路由通過位于 pod4 的命名空間（6）中的虛擬設備eth0來完成。一般來說，每個節(jié)點都知道如何將數(shù)據(jù)包傳遞給其內(nèi)部運行的 Pod，一旦數(shù)據(jù)包到達目標節(jié)點，數(shù)據(jù)包的流動方式與同一節(jié)點上的 Pod 間通信方式一樣。

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

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

Pod 到 Service

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

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

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

netfilter 與 iptables

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

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

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

IPVS

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

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

Pod 到 Service 通信

圖8. Pod 與 Service 之間通信

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

Service 到 Pod 通信

圖9.在 Service 和 Pod 之間通信

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

外網(wǎng)到 Service 通信

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

將流量從 Kubernetes 服務路由到互聯(lián)網(wǎng)上去

將流量從互聯(lián)網(wǎng)傳到你的 Kubernetes 服務

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

出流量

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

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

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

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

圖10.從Pod到互聯(lián)網(wǎng)通信

入流量

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

Service LoadBalancer

Ingress 控制器

LoadBalancer

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

LoadBalancer 到 Service

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

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

圖11.外網(wǎng)訪問 Service

Ingress 控制器

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

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

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

圖12.Ingress 控制器

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

Ingress 到 Service

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

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

圖13.從 Ingress 到 Service

總結

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