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

網(wǎng)絡(luò)所涉及的內(nèi)容很多，擁有許多成熟的技術(shù)。對于不熟悉的人來說可能會非常痛苦，因為大多數(shù)人對網(wǎng)絡(luò)都有先入為主的觀念，并且有很多新舊概念需要理解并組合成一個連貫的整體。所說的網(wǎng)絡(luò)可能包括網(wǎng)絡(luò)命名空間、虛擬接口、IP 轉(zhuǎn)發(fā)和網(wǎng)絡(luò)地址轉(zhuǎn)換等技術(shù)。本指南旨在通過討論每種 Kubernetes 相關(guān)技術(shù)以及如何使用這些技術(shù)來啟用 Kubernetes 網(wǎng)絡(luò)模型的描述來揭開 Kubernetes 網(wǎng)絡(luò)的神秘面紗。

本指南相當(dāng)長，分為幾個部分。我們首先討論一些基本的 Kubernetes 術(shù)語，以確保在整個指南中正確使用術(shù)語，然后討論 Kubernetes 網(wǎng)絡(luò)模型以及它強(qiáng)加的設(shè)計和實施決策。接下來是本指南中最長且最有趣的部分：??深入討論如何使用幾個不同的用例展示在Kubernetes內(nèi)是如何進(jìn)行通信的。??

文章大綱如下：

1、Kubernetes基礎(chǔ)知識

Kubernetes 由幾個核心概念構(gòu)建而成，這些概念組合成越來越強(qiáng)大的功能。本節(jié)列出了這些概念中的每一個，并提供了一個簡短的概述，以幫助促進(jìn)討論。Kubernetes 的內(nèi)容遠(yuǎn)不止此，這里僅僅簡要闡述一些基礎(chǔ)知識。如果您已經(jīng)熟悉 Kubernetes，請隨意跳過本節(jié)。

1.1、Kubernetes API server

在 Kubernetes 中，一切都是由 Kubernetes API 服務(wù)器（kube-apiserver）提供的 API 調(diào)用。API 服務(wù)器是 etcd 數(shù)據(jù)存儲的網(wǎng)關(guān)，它維護(hù)應(yīng)用程序集群的所需狀態(tài)。要更新 Kubernetes 集群的狀態(tài)，您可以對描述所需狀態(tài)的 API 服務(wù)器進(jìn)行 API 調(diào)用。

1.2、Controllers

控制器是用于構(gòu)建 Kubernetes 的核心抽象。一旦您使用 API 服務(wù)器聲明了集群的所需狀態(tài)，控制器就會通過持續(xù)觀察 API 服務(wù)器的狀態(tài)并對任何更改做出反應(yīng)來確保集群的當(dāng)前狀態(tài)與所需狀態(tài)相匹配。控制器內(nèi)部實現(xiàn)了一個循環(huán)，該循環(huán)不斷檢查集群的當(dāng)前狀態(tài)與集群的期望狀態(tài)。如果有任何差異，控制器將執(zhí)行任務(wù)以使當(dāng)前狀態(tài)與所需狀態(tài)匹配。在偽代碼中：

while true:
X = currentState()
Y = desiredState()

if X == Y:
return  # Do nothing
else:
    do(tasks to get to Y)

例如，當(dāng)您使用 API 服務(wù)器創(chuàng)建新 Pod 時，Kubernetes 調(diào)度程序（控制器）會注意到更改并決定將 Pod 放置在集群中的哪個位置。然后它使用 API 服務(wù)器（由 etcd 支持）寫入狀態(tài)更改。kubelet（一個控制器）然后會注意到新的變化并設(shè)置所需的網(wǎng)絡(luò)功能以使 Pod 在集群內(nèi)可訪問。在這里，兩個獨立的控制器對兩個獨立的狀態(tài)變化做出反應(yīng)，以使集群的現(xiàn)實與用戶的意圖相匹配。

1.3、Pods

Pod 是 Kubernetes 的原子——用于構(gòu)建應(yīng)用程序的最小可部署對象。單個 Pod 代表集群中正在運行的工作負(fù)載，并封裝了一個或多個 Docker 容器、任何所需的存儲和唯一的 IP 地址，組成 pod 的容器被設(shè)計為在同一臺機(jī)器上共同定位和調(diào)度。

1.4、Nodes

節(jié)點是運行 Kubernetes 集群的機(jī)器。這些可以是裸機(jī)、虛擬機(jī)或其他任何東西。主機(jī)一詞通常與節(jié)點互換使用。我將嘗試一致地使用術(shù)語節(jié)點，但有時會根據(jù)上下文使用虛擬機(jī)這個詞來指代節(jié)點。

2、Kubernetes網(wǎng)絡(luò)模型

Kubernetes 對 Pod 的聯(lián)網(wǎng)方式做出了自以為是的選擇。特別是，Kubernetes 對任何網(wǎng)絡(luò)實現(xiàn)都規(guī)定了以下要求：

• 所有 Pod 都可以在不使用網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT) 的情況下與所有其他 Pod 通信。
• 所有節(jié)點都可以在沒有 NAT 的情況下與所有 Pod 通信。
• Pod 認(rèn)為自己的 IP 與其他人認(rèn)為的 IP 相同。

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

• 容器到容器網(wǎng)絡(luò)
• Pod 到 Pod 網(wǎng)絡(luò)
• Pod 到服務(wù)網(wǎng)絡(luò)
• Internet 到服務(wù)網(wǎng)絡(luò)

本指南的其余部分將討論這些問題中的每一個 以及他們的解決方案。

3、容器和容器之間網(wǎng)絡(luò)通信

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

實際上，情況比這更微妙。在 Linux 中，每個正在運行的進(jìn)程都在一個網(wǎng)絡(luò)命名空間內(nèi)進(jìn)行通信，該命名空間為邏輯網(wǎng)絡(luò)堆棧提供了自己的路由、防火墻規(guī)則和網(wǎng)絡(luò)設(shè)備。本質(zhì)上，網(wǎng)絡(luò)命名空間為命名空間內(nèi)的所有進(jìn)程提供了一個全新的網(wǎng)絡(luò)堆棧。作為 Linux 用戶，可以使用 ip 命令創(chuàng)建網(wǎng)絡(luò)命名空間。例如，以下命令將創(chuàng)建一個名為 ns1 的新網(wǎng)絡(luò)命名空間。

$ ip netns add ns1

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

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

$ ls /var/run/netns
ns1
$ ip netns
ns1

默認(rèn)情況下，Linux 將每個進(jìn)程分配給根網(wǎng)絡(luò)命名空間以提供對外部世界的訪問，如圖 2 所示。

就 Docker 結(jié)構(gòu)而言，Pod 被建模為一組共享網(wǎng)絡(luò)命名空間的 Docker 容器。Pod 中的容器都具有相同的 IP 地址和端口空間，這些 IP 地址和端口空間是通過分配給 Pod 的網(wǎng)絡(luò)命名空間分配的，并且可以通過 localhost 找到彼此，因為它們位于同一個命名空間中。我們可以為虛擬機(jī)上的每個 Pod 創(chuàng)建一個網(wǎng)絡(luò)命名空間。這是使用 Docker 作為“Pod 容器”實現(xiàn)的，它保持網(wǎng)絡(luò)命名空間打開，而“應(yīng)用容器”（用戶指定的東西）通過 Docker 的 –net=container: 函數(shù)加入該命名空間。圖 3 顯示了每個 Pod 如何由共享命名空間內(nèi)的多個 Docker 容器 (ctr*) 組成。

Pod 中的應(yīng)用程序還可以訪問共享卷，這些卷被定義為 Pod 的一部分，并且可以掛載到每個應(yīng)用程序的文件系統(tǒng)中。

4、Pod和Pod之間網(wǎng)絡(luò)通信

在 Kubernetes 中，每個 Pod 都有一個真實的 IP 地址，并且每個 Pod 都使用該 IP 地址與其他 Pod 通信。現(xiàn)在任務(wù)是了解 Kubernetes 如何使用真實 IP 實現(xiàn) Pod 到 Pod 的通信，無論 Pod 部署在集群中的同一個物理節(jié)點還是不同的節(jié)點上。我們通過考慮駐留在同一臺機(jī)器上的 Pod 來開始這個討論，以避免通過內(nèi)部網(wǎng)絡(luò)跨節(jié)點通信的復(fù)雜性。

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

此時，我們已將 Pod 設(shè)置為每個都有自己的網(wǎng)絡(luò)命名空間，以便它們相信自己擁有自己的以太網(wǎng)設(shè)備和 IP 地址，并且它們連接到節(jié)點的根命名空間。現(xiàn)在，我們希望 Pod 通過根命名空間相互通信，為此我們使用網(wǎng)橋。

Linux 以太網(wǎng)網(wǎng)橋是一個虛擬的第 2 層網(wǎng)絡(luò)設(shè)備，用于聯(lián)合兩個或多個網(wǎng)段，透明地工作以將兩個網(wǎng)絡(luò)連接在一起。網(wǎng)橋通過檢查通過它的數(shù)據(jù)包的目的地并決定是否將數(shù)據(jù)包傳遞到連接到網(wǎng)橋的其他網(wǎng)段來維護(hù)源和目標(biāo)之間的轉(zhuǎn)發(fā)表來運行。橋接代碼通過查看網(wǎng)絡(luò)中每個以太網(wǎng)設(shè)備的唯一 MAC 地址來決定是橋接數(shù)據(jù)還是丟棄數(shù)據(jù)。

網(wǎng)橋?qū)崿F(xiàn) ARP 協(xié)議以發(fā)現(xiàn)與給定 IP 地址關(guān)聯(lián)的鏈路層 MAC 地址。當(dāng)網(wǎng)橋接收到數(shù)據(jù)幀時，網(wǎng)橋?qū)瑥V播到所有連接的設(shè)備（原始發(fā)送者除外），響應(yīng)該幀的設(shè)備存儲在查找表中。具有相同 IP 地址的未來流量使用查找表來發(fā)現(xiàn)將數(shù)據(jù)包轉(zhuǎn)發(fā)到的正確 MAC 地址。

圖5. 使用橋接連接網(wǎng)絡(luò)

4.1、同節(jié)點Pod通信

給定將每個 Pod 與自己的網(wǎng)絡(luò)堆棧隔離的網(wǎng)絡(luò)命名空間、將每個命名空間連接到根命名空間的虛擬以太網(wǎng)設(shè)備以及將命名空間連接在一起的網(wǎng)橋，我們終于準(zhǔn)備好在同一節(jié)點上的 Pod 之間進(jìn)行通信。這如圖 6 所示。

在圖 6 中，Pod 1 將數(shù)據(jù)包發(fā)送到它自己的以太網(wǎng)設(shè)備 eth0，該設(shè)備可用作 Pod 的默認(rèn)設(shè)備。對于 Pod 1，eth0 通過虛擬以太網(wǎng)設(shè)備連接到根命名空間 veth0 (1)。網(wǎng)橋 cbr0 配置有 veth0 連接到它的網(wǎng)段。一旦數(shù)據(jù)包到達(dá)網(wǎng)橋，網(wǎng)橋會解析正確的網(wǎng)段以使用 ARP 協(xié)議將數(shù)據(jù)包發(fā)送到 veth1 (3)。當(dāng)數(shù)據(jù)包到達(dá)虛擬設(shè)備 veth1 時，它被直接轉(zhuǎn)發(fā)到 Pod 2 的命名空間和該命名空間內(nèi)的 eth0 設(shè)備 (4)。在整個流量流中，每個 Pod 僅與 localhost 上的 eth0 通信，并且流量被路由到正確的 Pod。使用網(wǎng)絡(luò)的開發(fā)體驗是開發(fā)人員所期望的默認(rèn)行為。

Kubernetes 的網(wǎng)絡(luò)模型規(guī)定 Pod 必須可以通過其 IP 地址跨節(jié)點訪問。也就是說，一個 Pod 的 IP 地址始終對網(wǎng)絡(luò)中的其他 Pod 可見，每個 Pod 看待自己的 IP 地址的方式與其他 Pod 看待它的方式相同。我們現(xiàn)在轉(zhuǎn)向不同節(jié)點上的 Pod 之間如何進(jìn)行通信的問題。

4.2、跨節(jié)點Pod通信

在研究了如何在同一節(jié)點上的 Pod 之間如何進(jìn)行通信之后，我們繼續(xù)研究在不同節(jié)點上的 Pod 如何進(jìn)行通信。Kubernetes 網(wǎng)絡(luò)模型要求 Pod IP 可以通過網(wǎng)絡(luò)訪問，但它沒有指定必須如何完成。

通常，集群中的每個節(jié)點都分配有一個 CIDR 塊，指定該節(jié)點上運行的 Pod 可用的 IP 地址。一旦流向 CIDR 塊的流量到達(dá)節(jié)點，節(jié)點就有責(zé)任將流量轉(zhuǎn)發(fā)到正確的 Pod。圖 7 說明了兩個節(jié)點之間的流量流，假設(shè)網(wǎng)絡(luò)可以將 CIDR 塊中的流量路由到正確的節(jié)點。

圖 7 以與圖 6 相同的請求開始，但這次，目標(biāo) Pod（以綠色突出顯示）與源 Pod（以藍(lán)色突出顯示）位于不同的節(jié)點上。數(shù)據(jù)包首先通過 Pod 1 的以太網(wǎng)設(shè)備發(fā)送，該設(shè)備與根命名空間 (1) 中的虛擬以太網(wǎng)設(shè)備配對。最終，數(shù)據(jù)包最終到達(dá)根命名空間的網(wǎng)橋 (2)。ARP 將在網(wǎng)橋上失敗，因為沒有設(shè)備連接到網(wǎng)橋并具有正確的數(shù)據(jù)包 MAC 地址。失敗時，網(wǎng)橋?qū)?shù)據(jù)包發(fā)送到默認(rèn)路由——根命名空間的 eth0 設(shè)備。此時路由離開節(jié)點并進(jìn)入網(wǎng)絡(luò) (3)。我們現(xiàn)在假設(shè)網(wǎng)絡(luò)可以根據(jù)分配給節(jié)點的 CIDR 塊將數(shù)據(jù)包路由到正確的節(jié)點 (4)。數(shù)據(jù)包進(jìn)入目標(biāo)節(jié)點的根命名空間（VM 2 上的 eth0），在那里它通過網(wǎng)橋路由到正確的虛擬以太網(wǎng)設(shè)備 (5)。最后，路由通過位于 Pod 4 的命名空間 (6) 中的虛擬以太網(wǎng)設(shè)備對來完成。一般來說，每個節(jié)點都知道如何將數(shù)據(jù)包傳遞給在其中運行的 Pod。一旦數(shù)據(jù)包到達(dá)目標(biāo)節(jié)點，數(shù)據(jù)包的流動方式與在同一節(jié)點上的 Pod 之間路由流量的方式相同。

我們輕松地避開了如何配置網(wǎng)絡(luò)以將 Pod IP 的流量轉(zhuǎn)發(fā)到負(fù)責(zé)這些 IP 的正確節(jié)點。這是特定于網(wǎng)絡(luò)的，但查看特定示例將提供對所涉及問題的一些見解。例如，借助 AWS，Amazon 為 Kubernetes 維護(hù)了一個容器網(wǎng)絡(luò)插件，允許節(jié)點到節(jié)點網(wǎng)絡(luò)使用 [容器網(wǎng)絡(luò)接口 (CNI) 插件] (?https://github.com/aws/amazon)) 在 Amazon VPC 環(huán)境中運行-vpc-cni-k8s）。

容器網(wǎng)絡(luò)接口 (CNI) 提供了一個通用 API，用于將容器連接到外部網(wǎng)絡(luò)。作為開發(fā)人員，我們想知道 Pod 可以使用 IP 地址與網(wǎng)絡(luò)通信，并且我們希望此操作的機(jī)制是透明的。AWS 開發(fā)的 CNI 插件試圖滿足這些需求，同時通過 AWS 提供的現(xiàn)有 VPC、IAM 和安全組功能提供安全和可管理的環(huán)境，解決方案是使用彈性網(wǎng)絡(luò)接口。

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

5、Pod和Service之間網(wǎng)絡(luò)通信

我們已經(jīng)展示了如何在 Pod 及其關(guān)聯(lián)的 IP 地址之間路由轉(zhuǎn)發(fā)。在我們需要應(yīng)對變化之前，這很有效。Pod IP 地址不是持久的，并且會隨著擴(kuò)展或縮減、應(yīng)用程序崩潰或節(jié)點重啟而出現(xiàn)和消失。這些事件中的每一個都可以使 Pod IP 地址在沒有警告的情況下更改。Service被內(nèi)置到 Kubernetes 中來解決這個問題。

Kubernetes Service 管理一組 Pod 的狀態(tài)，允許您跟蹤一組隨時間動態(tài)變化的 Pod IP 地址。Service充當(dāng)對 Pod 的抽象，并將單個虛擬 IP 地址分配給一組 Pod IP 地址。任何發(fā)往 Service 虛擬 IP 的流量都將被轉(zhuǎn)發(fā)到與虛擬 IP 關(guān)聯(lián)的 Pod 集。這允許與 Service 關(guān)聯(lián)的 Pod 集隨時更改——客戶端只需要知道 Service 的虛擬 IP即可，它不會更改。

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

5.1、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ù)包到達(dá)計算機(jī)網(wǎng)絡(luò)中敏感位置的能力。

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

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

5.2、IPVS

Kubernetes 的最新版本 (1.11) 包括用于集群內(nèi)負(fù)載平衡的第二個選項：IPVS。IPVS（IP 虛擬服務(wù)器）也構(gòu)建在 netfilter 之上，并將傳輸層負(fù)載平衡作為 Linux 內(nèi)核的一部分實現(xiàn)。IPVS 被合并到 LVS（Linux

虛擬服務(wù)器）中，它在主機(jī)上運行并充當(dāng)真實服務(wù)器集群前面的負(fù)載平衡器。IPVS 可以將基于 TCP 和 UDP 的服務(wù)的請求定向到真實服務(wù)器，并使真實服務(wù)器的服務(wù)在單個 IP 地址上表現(xiàn)為虛擬服務(wù)。這使得 IPVS 非常適合 Kubernetes 服務(wù)。

聲明 Kubernetes Service時，您可以指定是否希望使用 iptables 或 IPVS 完成集群內(nèi)負(fù)載平衡。IPVS 專為負(fù)載平衡而設(shè)計，并使用更高效的數(shù)據(jù)結(jié)構(gòu)（哈希表），與 iptables 相比允許幾乎無限的規(guī)模。在使用 IPVS 創(chuàng)建負(fù)載均衡的 Service 時，會發(fā)生三件事：在 Node 上創(chuàng)建一個虛擬 IPVS 接口，將 Service 的 IP 地址綁定到虛擬 IPVS 接口，并為每個 Service IP 地址創(chuàng)建 IPVS 服務(wù)器。

未來，IPVS 有望成為集群內(nèi)負(fù)載均衡的默認(rèn)方法。此更改僅影響集群內(nèi)負(fù)載平衡，并且在本指南的其余部分中，您可以安全地將 iptables 替換為 IPVS 以實現(xiàn)集群內(nèi)負(fù)載平衡，而不會影響其余討論。現(xiàn)在讓我們看看通過集群內(nèi)負(fù)載平衡服務(wù)的數(shù)據(jù)包的生命周期。

5.3、Pod和Service通信

在 Pod 和 Service 之間路由數(shù)據(jù)包時，與以前相同的方式開始。數(shù)據(jù)包首先通過連接到 Pod 的網(wǎng)絡(luò)命名空間 (1) 的 eth0 接口離開 Pod。然后它通過虛擬以太網(wǎng)設(shè)備到達(dá)網(wǎng)橋 (2)。網(wǎng)橋上運行的 ARP 協(xié)議不知道 Service，因此它通過默認(rèn)路由 eth0 (3) 將數(shù)據(jù)包傳輸出去。在這里，發(fā)生了一些不同的事情。在 eth0 接受之前，數(shù)據(jù)包會通過 iptables 過濾。iptables 收到數(shù)據(jù)包后，使用 kube-proxy 安裝在 Node 上的規(guī)則響應(yīng) Service 或 Pod 事件，將數(shù)據(jù)包的目的地從 Service IP 重寫為特定的 Pod IP（4）。數(shù)據(jù)包現(xiàn)在注定要到達(dá) Pod 4，而不是服務(wù)的虛擬 IP。iptables 利用 Linux 內(nèi)核的 conntrack 實用程序來記住所做的 Pod 選擇，以便將來的流量路由到同一個 Pod（除非發(fā)生任何擴(kuò)展事件）。本質(zhì)上，iptables 直接在 Node 上做了集群內(nèi)負(fù)載均衡。然后流量使用我們已經(jīng)檢查過的 Pod 到 Pod 路由流向 Pod (5)。

5.4、Service和Pod通信

收到此數(shù)據(jù)包的 Pod 將響應(yīng)，將源 IP 識別為自己的 IP，將目標(biāo) IP 識別為最初發(fā)送數(shù)據(jù)包的 Pod (1)。進(jìn)入節(jié)點后，數(shù)據(jù)包流經(jīng) iptables，它使用 conntrack 記住它之前所做的選擇，并將數(shù)據(jù)包的源重寫為服務(wù)的 IP 而不是 Pod 的 IP (2)。從這里開始，數(shù)據(jù)包通過網(wǎng)橋流向與 Pod 的命名空間配對的虛擬以太網(wǎng)設(shè)備 (3)，然后流向我們之前看到的 Pod 的以太網(wǎng)設(shè)備 (4)。

5.5、使用DNS

Kubernetes 可以選擇使用 DNS 來避免將服務(wù)的集群 IP 地址硬編碼到您的應(yīng)用程序中。Kubernetes DNS 作為在集群上調(diào)度的常規(guī) Kubernetes 服務(wù)運行。它配置在每個節(jié)點上運行的 kubelet，以便容器使用 DNS 服務(wù)的 IP 來解析 DNS 名稱。集群中定義的每個服務(wù)（包括 DNS 服務(wù)器本身）都被分配了一個 DNS 名稱。DNS 記錄將 DNS 名稱解析為服務(wù)的集群 IP 或 POD 的 IP，具體取決于您的需要。SRV 記錄用于指定運行服務(wù)的特定命名端口。

DNS Pod 由三個獨立的容器組成：

• kubedns：監(jiān)視 Kubernetes 主服務(wù)器的服務(wù)和端點變化，并維護(hù)內(nèi)存中的查找結(jié)構(gòu)以服務(wù) DNS 請求。
• dnsmasq：添加 DNS 緩存以提高性能。
• sidecar：提供一個單一的健康檢查端點來執(zhí)行 dnsmasq 和 kubedns 的健康檢查。

DNS Pod 本身作為 Kubernetes 服務(wù)公開，具有靜態(tài)集群 IP，該 IP 在啟動時傳遞給每個正在運行的容器，以便每個容器都可以解析 DNS 條目。DNS 條目通過維護(hù)內(nèi)存中 DNS 表示的 kubedns 系統(tǒng)解析。etcd 是集群狀態(tài)的后端存儲系統(tǒng)，kubedns 使用一個庫將 etcd 鍵值存儲轉(zhuǎn)換為 DNS 整體，以便在必要時重建內(nèi)存中 DNS 查找結(jié)構(gòu)的狀態(tài)。

CoreDNS 與 kubedns 的工作方式類似，但使用插件架構(gòu)構(gòu)建，使其更加靈活。從 Kubernetes 1.11 開始，CoreDNS 是 Kubernetes 的默認(rèn) DNS 實現(xiàn)。

6、Internet和Service之間網(wǎng)絡(luò)通信

到目前為止，我們已經(jīng)了解了 Kubernetes 集群內(nèi)的流量是如何轉(zhuǎn)發(fā)的。這一切都很好，但不幸的是，將您的應(yīng)用程序與外界隔離無助于實現(xiàn)任何銷售目標(biāo)——在某些時候，您可能希望將您的服務(wù)暴露給外部流量。這種需求突出了兩個相關(guān)的問題：（1）從 Kubernetes 服務(wù)獲取流量到 Internet。（2）從 Internet 獲取流量到您的 Kubernetes 服務(wù)。

6.1、Egress-將Kubernetes流量轉(zhuǎn)發(fā)到Internet

從節(jié)點到公共 Internet 的流量轉(zhuǎn)發(fā)是特定于網(wǎng)絡(luò)的，并且實際上取決于您的網(wǎng)絡(luò)如何配置以發(fā)布流量。為了使本節(jié)更加具體，我將使用 AWS VPC 來討論任何具體細(xì)節(jié)。

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

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

6.1.1、Node和Internet通信

在下圖中，數(shù)據(jù)包源自 Pod 的命名空間 (1)，并經(jīng)過連接到根命名空間 (2) 的 veth 對。一旦進(jìn)入根命名空間，數(shù)據(jù)包就會從網(wǎng)橋移動到默認(rèn)設(shè)備，因為數(shù)據(jù)包上的 IP 與連接到網(wǎng)橋的任何網(wǎng)段都不匹配。在到達(dá)根命名空間的以太網(wǎng)設(shè)備 (3) 之前，iptables 會破壞數(shù)據(jù)包 (3)。在這種情況下，數(shù)據(jù)包的源 IP 地址是 Pod，如果我們將源保留為 Pod，Internet 網(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) 并到達(dá) Internet 網(wǎng)關(guān) (5)。Internet 網(wǎng)關(guān)將執(zhí)行另一個 NAT，將源 IP 從 VM 內(nèi)部 IP 重寫為外部 IP。最后，數(shù)據(jù)包將到達(dá)公共 Internet (6)。在返回的路上，數(shù)據(jù)包遵循相同的路徑，并且任何源 IP 修改都被撤消，以便系統(tǒng)的每一層都接收到它理解的 IP 地址：節(jié)點或 VM 級別的 VM 內(nèi)部，以及 Pod 內(nèi)的 Pod IP命名空間。

6.2、Ingress-將Internet流量轉(zhuǎn)發(fā)到Kubernetes

入口——讓流量進(jìn)入你的集群——是一個非常難以解決的問題。同樣，這是特定于您正在運行的網(wǎng)絡(luò)的，但一般來說，Ingress 分為兩種解決方案，適用于網(wǎng)絡(luò)堆棧的不同部分：(1) 服務(wù)負(fù)載平衡器和 (2) 入口控制器

6.2.1、四層轉(zhuǎn)發(fā)-Loadbalancer

當(dāng)你創(chuàng)建一個 Kubernetes 服務(wù)時，你可以選擇指定一個 LoadBalancer 來配合它。LoadBalancer 的實現(xiàn)由知道如何為您的服務(wù)創(chuàng)建負(fù)載均衡器的云控制器提供。創(chuàng)建服務(wù)后，它將公布負(fù)載均衡器的 IP 地址。作為最終用戶，您可以開始將流量引導(dǎo)到負(fù)載均衡器以開始與您的服務(wù)通信。

借助 AWS，負(fù)載均衡器可以了解其目標(biāo)組中的節(jié)點，并將平衡集群中所有節(jié)點的流量。一旦流量到達(dá)一個節(jié)點，之前為您的服務(wù)在整個集群中安裝的 iptables 規(guī)則將確保流量到達(dá)您感興趣的服務(wù)的 Pod。

6.2.2、Loadbalancer和Service通信

讓我們看看這在實踐中是如何工作的。部署服務(wù)后，您正在使用的云提供商將為您創(chuàng)建一個新的負(fù)載均衡器 (1)。因為負(fù)載均衡器不支持容器，所以一旦流量到達(dá)負(fù)載均衡器，它就會分布在組成集群的所有虛擬機(jī)中 (2)。每個 VM 上的 iptables 規(guī)則會將來自負(fù)載均衡器的傳入流量引導(dǎo)到正確的 Pod (3) — 這些是在服務(wù)創(chuàng)建期間實施并在前面討論過的相同 IP 表規(guī)則。Pod 到客戶端的響應(yīng)將返回 Pod 的 IP，但客戶端需要有負(fù)載均衡器的 IP 地址。正如我們之前看到的，iptables 和 conntrack 用于在返回路徑上正確重寫 IP。

下圖顯示了托管 Pod 的三個 VM 前面的網(wǎng)絡(luò)負(fù)載均衡器。傳入流量 (1) 指向您的服務(wù)的負(fù)載均衡器。一旦負(fù)載均衡器收到數(shù)據(jù)包 (2)，它就會隨機(jī)選擇一個 VM。在這種情況下，我們病態(tài)地選擇了沒有運行 Pod 的 VM：VM 2 (3)。在這里，運行在 VM 上的 iptables 規(guī)則將使用 kube-proxy 安裝到集群中的內(nèi)部負(fù)載平衡規(guī)則將數(shù)據(jù)包定向到正確的 Pod。iptables 執(zhí)行正確的 NAT 并將數(shù)據(jù)包轉(zhuǎn)發(fā)到正確的 Pod (4)。

6.2.3、七層轉(zhuǎn)發(fā)-Ingress Controller

第 7 層網(wǎng)絡(luò) Ingress 在網(wǎng)絡(luò)堆棧的 HTTP/HTTPS 協(xié)議范圍內(nèi)運行，并構(gòu)建在 Services 之上。啟用 Ingress 的第一步是使用 Kubernetes 中的 NodePort 服務(wù)類型在您的服務(wù)上打開一個端口。如果將 Service 的 type 字段設(shè)置為 NodePort，Kubernetes master 將從您指定的范圍內(nèi)分配一個端口，并且每個 Node 都會將該端口（每個 Node 上的相同端口號）代理到您的 Service 中。也就是說，任何指向節(jié)點端口的流量都將使用 iptables 規(guī)則轉(zhuǎn)發(fā)到服務(wù)。這個 Service 到 Pod 的路由遵循我們在將流量從 Service 路由到 Pod 時已經(jīng)討論過的相同的內(nèi)部集群負(fù)載平衡模式。

要向 Internet 公開節(jié)點的端口，您需要使用 Ingress 對象。Ingress 是一個更高級別的 HTTP 負(fù)載均衡器，它將 HTTP 請求映射到 Kubernetes 服務(wù)。Ingress 方法將根據(jù) Kubernetes 云提供商控制器的實現(xiàn)方式而有所不同。HTTP 負(fù)載均衡器，如第 4 層網(wǎng)絡(luò)負(fù)載均衡器，僅了解節(jié)點 IP（而不是 Pod IP），因此流量路由同樣利用由 kube-proxy 安裝在每個節(jié)點上的 iptables 規(guī)則提供的內(nèi)部負(fù)載均衡。

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

創(chuàng)建后，(1) Ingress Controller 監(jiān)視來自 Kubernetes API 服務(wù)器的 Ingress 事件。當(dāng)它找到滿足其要求的 Ingress 資源時，它會開始創(chuàng)建 AWS 資源。AWS 將 Application Load Balancer (ALB) (2) 用于

Ingress 資源。負(fù)載均衡器與用于將請求路由到一個或多個注冊節(jié)點的目標(biāo)組一起工作。(3) 在 AWS 中為 Ingress 資源描述的每個唯一 Kubernetes 服務(wù)創(chuàng)建目標(biāo)組。(4) Listener 是一個 ALB 進(jìn)程，它使用您配置的協(xié)議和端口檢查連接請求。偵聽器由 Ingress 控制器為您的 Ingress 資源注釋中詳述的每個端口創(chuàng)建。最后，為 Ingress 資源中指定的每個路徑創(chuàng)建目標(biāo)組規(guī)則。這確保了到特定路徑的流量被路由到正確的 Kubernetes 服務(wù) (5)。

6.2.4、Ingress和Service通信

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

讓我們看看這在實踐中是如何工作的。部署服務(wù)后，您正在使用的云提供商將為您創(chuàng)建一個新的 Ingress 負(fù)載均衡器 (1)。由于負(fù)載均衡器不支持容器，因此一旦流量到達(dá)負(fù)載均衡器，它就會通過為您的服務(wù)提供的廣告端口分布在組成集群 (2) 的整個 VM 中。每個 VM 上的 iptables 規(guī)則會將來自負(fù)載均衡器的傳入流量引導(dǎo)到正確的 Pod (3) — 正如我們之前所見。Pod 到客戶端的響應(yīng)將返回 Pod 的 IP，但客戶端需要有負(fù)載均衡器的 IP 地址。正如我們之前看到的，iptables 和 conntrack 用于在返回路徑上正確重寫 IP。

第 7 層負(fù)載均衡器的一個好處是它們可以識別 HTTP，因此它們知道 URL 和路徑。這使您可以按 URL 路徑對服務(wù)流量進(jìn)行分段。它們通常還在 HTTP 請求的 X-Forwarded-For 標(biāo)頭中提供原始客戶端的 IP 地址。

7、總結(jié)

本指南為理解 Kubernetes 網(wǎng)絡(luò)模型以及它如何支持常見的網(wǎng)絡(luò)任務(wù)奠定了基礎(chǔ)。網(wǎng)絡(luò)領(lǐng)域既廣泛又深入，不可能在這里涵蓋所有內(nèi)容。本指南應(yīng)為您提供深入了解您感興趣并想了解更多主題的起點。每當(dāng)您遇到困難時，請利用 Kubernetes 文檔和 Kubernetes 社區(qū)來幫助您找到自己的方式。

8、網(wǎng)絡(luò)術(shù)語

Kubernetes 依賴于幾種現(xiàn)有技術(shù)來構(gòu)建一個正常運行的集群。全面探索這些技術(shù)中的每一個超出了本指南的范圍，但本節(jié)將詳細(xì)描述這些技術(shù)中的每一個，以便進(jìn)行討論。如果您感到困惑或需要復(fù)習(xí)，您可以隨意略讀本節(jié)，完全跳過它，或者根據(jù)需要參考它。

二層網(wǎng)絡(luò)

第 2 層是提供節(jié)點到節(jié)點數(shù)據(jù)傳輸?shù)臄?shù)據(jù)鏈路層。它定義了在兩個物理連接的設(shè)備之間建立和終止連接的協(xié)議。它還定義了它們之間的流量控制協(xié)議。

四層網(wǎng)絡(luò)

傳輸層通過流量控制控制給定鏈路的可靠性。在 TCP/IP 中，這一層是指用于在不可靠網(wǎng)絡(luò)上交換數(shù)據(jù)的 TCP 協(xié)議。

七層網(wǎng)絡(luò)

應(yīng)用層是最接近最終用戶的層，這意味著應(yīng)用層和用戶都直接與軟件應(yīng)用程序交互。該層與實現(xiàn)通信組件的軟件應(yīng)用程序交互。通常，第 7 層網(wǎng)絡(luò)是指 HTTP。

Nat網(wǎng)絡(luò)地址轉(zhuǎn)換

NAT 或網(wǎng)絡(luò)地址轉(zhuǎn)換是將一個地址空間重新映射到另一個地址空間的 IP 級別。映射通過在數(shù)據(jù)包通過流量路由設(shè)備傳輸時修改數(shù)據(jù)包的 IP 標(biāo)頭中的網(wǎng)絡(luò)地址信息來實現(xiàn)。

基本 NAT 是從一個 IP 地址到另一個 IP 地址的簡單映射。更常見的是，NAT 用于將多個私有 IP 地址映射到一個公開的 IP 地址。通常，本地網(wǎng)絡(luò)使用私有 IP 地址空間，并且該網(wǎng)絡(luò)上的路由器在該空間中被賦予私有地址。然后路由器使用公共 IP 地址連接到 Internet。當(dāng)流量從本地網(wǎng)絡(luò)傳遞到 Internet 時，每個數(shù)據(jù)包的源地址都從私有地址轉(zhuǎn)換為公共地址，這使得請求看起來好像直接來自路由器。路由器維護(hù)連接跟蹤，以將回復(fù)轉(zhuǎn)發(fā)到本地網(wǎng)絡(luò)上的正確專用 IP。

NAT 提供了一個額外的好處，即允許大型專用網(wǎng)絡(luò)使用單個公共 IP 地址連接到 Internet，從而節(jié)省公共使用的 IP 地址的數(shù)量。

snat-源地址轉(zhuǎn)換

SNAT 只是指修改 IP 數(shù)據(jù)包源地址的 NAT 過程。這是上述 NAT 的典型行為。

dnat-目標(biāo)地址轉(zhuǎn)換

DNAT 是指修改 IP 數(shù)據(jù)包的目的地址的 NAT 過程。DNAT 用于將位于專用網(wǎng)絡(luò)中的服務(wù)發(fā)布到可公開尋址的 IP 地址。

網(wǎng)絡(luò)名稱空間

在網(wǎng)絡(luò)中，每臺機(jī)器（真實的或虛擬的）都有一個以太網(wǎng)設(shè)備（我們將其稱為 eth0）。所有流入和流出機(jī)器的流量都與該設(shè)備相關(guān)聯(lián)。事實上，Linux 將每個以太網(wǎng)設(shè)備與一個網(wǎng)絡(luò)命名空間相關(guān)聯(lián)——整個網(wǎng)絡(luò)堆棧的邏輯副本，以及它自己的路由、防火墻規(guī)則和網(wǎng)絡(luò)設(shè)備。最初，所有進(jìn)程共享來自 init 進(jìn)程的相同默認(rèn)網(wǎng)絡(luò)命名空間，稱為根命名空間。默認(rèn)情況下，進(jìn)程從其父進(jìn)程繼承其網(wǎng)絡(luò)命名空間，因此，如果您不進(jìn)行任何更改，所有網(wǎng)絡(luò)流量都會流經(jīng)為根網(wǎng)絡(luò)命名空間指定的以太網(wǎng)設(shè)備。

veth虛擬網(wǎng)卡對

計算機(jī)系統(tǒng)通常由一個或多個網(wǎng)絡(luò)設(shè)備（eth0、eth1 等）組成，這些設(shè)備與負(fù)責(zé)將數(shù)據(jù)包放置到物理線路上的物理網(wǎng)絡(luò)適配器相關(guān)聯(lián)。Veth 設(shè)備是虛擬網(wǎng)絡(luò)設(shè)備，始終以互連的對創(chuàng)建。它們可以充當(dāng)網(wǎng)絡(luò)命名空間之間的隧道，以創(chuàng)建到另一個命名空間中的物理網(wǎng)絡(luò)設(shè)備的橋接，但也可以用作獨立的網(wǎng)絡(luò)設(shè)備。您可以將

veth 設(shè)備視為設(shè)備之間的虛擬跳線——一端連接的設(shè)備將連接另一端。

網(wǎng)絡(luò)橋接

網(wǎng)橋是從多個通信網(wǎng)絡(luò)或網(wǎng)段創(chuàng)建單個聚合網(wǎng)絡(luò)的設(shè)備。橋接連接兩個獨立的網(wǎng)絡(luò)，就好像它們是一個網(wǎng)絡(luò)一樣。橋接使用內(nèi)部數(shù)據(jù)結(jié)構(gòu)來記錄每個數(shù)據(jù)包發(fā)送到的位置，以作為性能優(yōu)化。

CIDR

CIDR 是一種分配 IP 地址和執(zhí)行 IP 路由的方法。對于 CIDR，IP 地址由兩組組成：網(wǎng)絡(luò)前綴（標(biāo)識整個網(wǎng)絡(luò)或子網(wǎng)）和主機(jī)標(biāo)識符（指定該網(wǎng)絡(luò)或子網(wǎng)上的主機(jī)的特定接口）。CIDR 使用 CIDR 表示法表示 IP

地址，其中地址或路由前綴寫有表示前綴位數(shù)的后綴，例如 IPv4 的 192.0.2.0/24。IP 地址是 CIDR 塊的一部分，如果地址的初始

n 位和 CIDR 前綴相同，則稱其屬于 CIDR 塊。

CNI

CNI（容器網(wǎng)絡(luò)接口）是一個云原生計算基金會項目，由規(guī)范和庫組成，用于編寫插件以在 Linux 容器中配置網(wǎng)絡(luò)接口。CNI 只關(guān)心容器的網(wǎng)絡(luò)連接以及在容器被刪除時移除分配的資源。

VIP地址

虛擬 IP 地址或 VIP 是軟件定義的 IP 地址，與實際的物理網(wǎng)絡(luò)接口不對應(yīng)。

netfilter

netfilter 是 Linux 中的包過濾框架。實現(xiàn)此框架的軟件負(fù)責(zé)數(shù)據(jù)包過濾、網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT) 和其他數(shù)據(jù)包處理。

netfilter、ip_tables、連接跟蹤（ip_conntrack、nf_conntrack）和NAT子系統(tǒng)共同構(gòu)建了框架的主要部分。

iptables

iptables 是一個允許 Linux 系統(tǒng)管理員配置 netfilter 及其存儲的鏈和規(guī)則的程序。IP 表中的每條規(guī)則都由許多分類器（iptables 匹配）和一個連接的操作（iptables 目標(biāo)）組成。

conntrack

conntrack 是建立在 Netfilter 框架之上的用于處理連接跟蹤的工具。連接跟蹤允許內(nèi)核跟蹤所有邏輯網(wǎng)絡(luò)連接或會話，并將每個連接或會話的數(shù)據(jù)包定向到正確的發(fā)送者或接收者。NAT

依靠此信息以相同的方式翻譯所有相關(guān)數(shù)據(jù)包，并且 iptables 可以使用此信息充當(dāng)狀態(tài)防火墻。

IPVS

IPVS 將傳輸層負(fù)載平衡作為 Linux 內(nèi)核的一部分來實現(xiàn)。

IPVS 是一個類似于 iptables 的工具。它基于 Linux 內(nèi)核的 netfilter 鉤子函數(shù)，但使用哈希表作為底層數(shù)據(jù)結(jié)構(gòu)。這意味著，與 iptables 相比，IPVS 重定向流量更快，在同步代理規(guī)則時具有更好的性能，并提供更多的負(fù)載平衡算法。

DNS

域名系統(tǒng) (DNS) 是一個分散的命名系統(tǒng)，用于將系統(tǒng)名稱與 IP 地址相關(guān)聯(lián)。它將域名轉(zhuǎn)換為用于定位計算機(jī)服務(wù)的數(shù)字 IP 地址。