Kubernetes 網(wǎng)絡(luò)模型如何實現(xiàn)常見網(wǎng)絡(luò)任務(wù)

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

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

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

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

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

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

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

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

Pod 到 Pod 的網(wǎng)絡(luò)

Pod 到 Service 的網(wǎng)絡(luò)

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

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

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

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

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

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

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

$ipnetnsaddns1

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

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

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

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

圖2.root network namespace

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

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

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

Pod 到 Pod 網(wǎng)絡(luò)

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

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

圖4.Pod 的 veth 對

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

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

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

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

同節(jié)點 Pod 通信

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

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

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

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

跨節(jié)點 Pod 通信

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

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

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

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

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

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

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

Pod 到 Service

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

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

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

netfilter 與 iptables

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

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

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

IPVS

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

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

Pod 到 Service 通信

圖8. Pod 與 Service 之間通信

當(dāng)這 Pod 和 Service 之間路由一個數(shù)據(jù)包時，流量和以前開始的方式一樣，數(shù)據(jù)包首先通過連接到 Pod 的網(wǎng)絡(luò)命名空間（1）的eth0離開 Pod，。然后它通過虛擬網(wǎng)絡(luò)設(shè)備到達網(wǎng)橋（2）。網(wǎng)橋上運行的 ARP 是不知道 Service 地址的，所以它通過默認(rèn)路由eth0（3）將數(shù)據(jù)包傳輸出去。到這里會有一些不同的地方了，在eth0接收之前，該數(shù)據(jù)包會被 iptables 過濾，在收到數(shù)據(jù)包后，iptables 使用 kube-proxy 在節(jié)點上安裝的規(guī)則來響應(yīng) 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)的負(fù)載均衡，然后流量流向 Pod，剩下的就和前面的 Pod 到 Pod 通信一樣的了（5）。

Service 到 Pod 通信

圖9.在 Service 和 Pod 之間通信

相應(yīng)的回包的時候，收到該數(shù)據(jù)包的 Pod 將響應(yīng)，將源 IP 標(biāo)記為自己的 IP，將目標(biāo) IP 標(biāo)記為最初發(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)絡(luò)設(shè)備 (3)，然后流向我們之前看到的 Pod 的虛擬網(wǎng)絡(luò)設(shè)備 (4)。

外網(wǎng)到 Service 通信

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

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

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

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

出流量

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

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

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

在下圖中，數(shù)據(jù)包源自 Pod 的命名空間 (1)，并經(jīng)過連接到根命名空間 (2) 的 veth 對。一旦進入根命名空間，數(shù)據(jù)包就會從網(wǎng)橋移動到默認(rèn)設(shè)備，因為數(shù)據(jù)包上的 IP 與連接到網(wǎng)橋的任何網(wǎng)段都不匹配。在到達根命名空間的網(wǎng)絡(luò)設(shè)備 (3) 之前，iptables 會破壞數(shù)據(jù)包 (3)。在這種情況下，數(shù)據(jù)包的源 IP 地址是 Pod，如果我們將源保留為 Pod，外網(wǎng)網(wǎng)關(guān)將拒絕它，因為網(wǎng)關(guān) NAT 只了解連接到 VM 的 IP 地址。解決方案是讓 iptables 執(zhí)行源 NAT—— 更改數(shù)據(jù)包源，使數(shù)據(jù)包看起來來自 VM 而不是 Pod。有了正確的源 IP，數(shù)據(jù)包現(xiàn)在可以離開 VM (4) 并到達外網(wǎng)網(wǎng)關(guān) (5) 了。外網(wǎng)網(wǎng)關(guān)將執(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)絡(luò)環(huán)境有關(guān)系，但是一般來說入流量可以分為兩種解決方案：

Service LoadBalancer

Ingress 控制器

LoadBalancer

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

LoadBalancer 到 Service

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

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

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

Ingress 控制器

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

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

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

圖12.Ingress 控制器

創(chuàng)建后，(1) Ingress Controller 會 watch 來自 Kubernetes APIServer 的 Ingress 事件。當(dāng)它找到滿足其要求的 Ingress 資源時，它會開始創(chuàng)建 AWS 資源。AWS 將 Application Load Balancer (ALB) (2) 用于 Ingress 資源。負(fù)載均衡器與用于將請求路由到一個或多個注冊節(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 服務(wù)上 (5)。

Ingress 到 Service

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

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

圖13.從 Ingress 到 Service

總結(jié)

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