大家好，我是二哥。

這期為什么會(huì)寫(xiě)這個(gè)主題呢?因?yàn)?K8s 里面的 IP 類型實(shí)在是太多了，多到讓你在使用的時(shí)候暈頭轉(zhuǎn)向。這次我們借助一個(gè)(虛擬的)例子來(lái)看看使用 K8s 的時(shí)候，會(huì)涉及到哪些類型的 IP 地址。

1、示例介紹

我們的示例涉及到的主要模塊有：客戶端、L4 Load balancer、Nginx-Ingress、k8s 環(huán)境、外部服務(wù)(https://api.bank.com)。

客戶端想要訪問(wèn)的服務(wù)是 https://api.2ge.com/pathA。在 K8s 內(nèi)部，由兩個(gè) service 分別依次處理這個(gè)請(qǐng)求：front-end.lance.svc.cluster.local 和 bill.lance.svc.cluster.local 。前者的角色從它的名字就可以看出來(lái)，而后者用于處理賬單類事務(wù)。當(dāng)然涉及到錢的時(shí)候，總離不開(kāi)和銀行打交道，所以 service bill 還會(huì)調(diào)用外部的一家銀行所提供的服務(wù) https://api.bank.com 做進(jìn)一步的處理。下圖展示了上述模塊的組成以及整個(gè)調(diào)用鏈。與負(fù)載均衡工作時(shí)所處的 OSI 網(wǎng)絡(luò)模型層級(jí)相關(guān)，返回路徑既可能經(jīng)過(guò)原節(jié)點(diǎn)，也可能繞過(guò)原節(jié)點(diǎn)形成一個(gè)三角傳輸模式，所以這張圖里沒(méi)有畫(huà)出返回路徑。

2、L4 LB IP

① 客戶端當(dāng)然首先通過(guò) DNS 獲知 FQDN api.2ge.com 的 IP 地址。只不過(guò)客戶端不知道的是這個(gè)地址是綁在 L4 load balancer (LB) 上的。這里的 IP 地址是一個(gè) public IP 。如果我們使用的是云服務(wù)，那當(dāng)使用它們的 LB 的時(shí)候，會(huì)非常容易地得到一個(gè)固定的 public IP 。這里的 LB 工作在 L3/L4 。所謂四層負(fù)載均衡，也就是主要通過(guò)包的四層信息( src/dst ip, src/dst port, proto)，再加上負(fù)載均衡設(shè)備所設(shè)置的服務(wù)器選擇方式，決定最終選擇的內(nèi)部服務(wù)器。它是一種基于IP+端口的負(fù)載均衡方式。這里所提及的服務(wù)器選擇方式其實(shí)是一種策略，譬如有輪循均衡(Round Robin)、隨機(jī)均衡(Random)、響應(yīng)速度均衡(Response Time)等等。簡(jiǎn)言之：負(fù)載均衡的兩大職責(zé)是“選擇誰(shuí)來(lái)處理用戶請(qǐng)求”和“將用戶請(qǐng)求轉(zhuǎn)發(fā)過(guò)去”。當(dāng) LB 決定將請(qǐng)求轉(zhuǎn)交給它背后的服務(wù)時(shí)，它首先需要修改網(wǎng)絡(luò)包的源 IP 地址和目的 IP 地址：將源地址改成自己的 IP ，而將目的 IP 地址改成圖中 Nginx-Ingress 所擁有的 private IP。

3、Ingress IP

② 沿著請(qǐng)求路徑，將我們的目光轉(zhuǎn)移到 Ingress 身上。這里我們用的是 Nginx-Ingress 。我們給它分配的是 private IP 地址，如 192.168.5.20/16。這意味著這里的 Ingress 只能工作在 L4 LB 后面。

為什么不把 Ingress 直接通過(guò) public IP 暴露在 internet 上呢?答案當(dāng)然是可以的。只是 L4 LB 只是單純地轉(zhuǎn)發(fā)包，且這個(gè)過(guò)程不需要和上下游建立連接。相比于 Nginx ，它的抗負(fù)載能力強(qiáng)、性能高(能相對(duì)靠近 F5 或 A10 硬件性能)，對(duì)內(nèi)存和cpu資源消耗比較低。從這里我們也可以看出來(lái)多級(jí)混合負(fù)載均衡的時(shí)候，通常應(yīng)是工作在OSI 網(wǎng)絡(luò)模型低層的負(fù)載均衡在前，而工作在高層的負(fù)載均衡在后。因?yàn)?Ingress 工作在 L7 ，所以它更懂應(yīng)用層的協(xié)議，比如它可以理解 HTTP 請(qǐng)求里面的 path ，并基于 path 做進(jìn)一步的路由。

4、service IP

③ 既然說(shuō) Ingress 更懂 HTTP ，當(dāng)它得知客戶的請(qǐng)求路徑是 /pathA 后，它就知道需要把請(qǐng)求轉(zhuǎn)向內(nèi)部的 service front-end.lance.svc.cluster.local。

步驟 ③ 這里發(fā)生的是 TCP 連接，所以 Ingress和 service 之間的三次握手、數(shù)據(jù)通信、四次揮手一個(gè)都不能少。相比步驟 ① 和 ② 之間的純 IP 轉(zhuǎn)發(fā)，這些多出來(lái)的步驟顯然笨重了許多。但這個(gè)世界上的東西沒(méi)有絕對(duì)的優(yōu)點(diǎn)和缺點(diǎn)。當(dāng) ③ 得知了訪問(wèn)所請(qǐng)求的 path 之后，也便對(duì)通信內(nèi)容有了更多的了解，當(dāng)然也就有了更多的話語(yǔ)權(quán)，自然就能做更智能、更復(fù)雜的流量監(jiān)控。比如我們可以以 REST API 為粒度來(lái)統(tǒng)計(jì)訪問(wèn)流量、延遲、錯(cuò)誤率等。步驟 ③ 既可能是基于 HTTP Proxy，也可能是 HTTPS Proxy的。二哥在文章《??手邊的tunnel知多少??》里對(duì) HTTPS Proxy 做了較詳細(xì)的解釋，歡迎翻閱。當(dāng)我們創(chuàng)建 K8s service 的時(shí)候，一定會(huì)需要做一個(gè)選擇：service 類型是什么?事實(shí)上，目前我們可以選擇的有：NodePort 、ClusterIP、LoadBalancer、ExternalName。不同的選擇會(huì)出現(xiàn)不同的 IP 類型。

（1） NodePort

當(dāng)我們選擇 NodePort 類型意味著我們可以用 Node 自身的 IP 地址搭配在 Node 上所開(kāi)啟的端口訪問(wèn)該服務(wù)。下圖展示了在這種類型下，客戶端通過(guò)向 Node1 的 IP 地址(端口未畫(huà)出)發(fā)起請(qǐng)求，但最終由位于 Node2上的 Pod B 提供服務(wù)的流程。圖中 kube-proxy 利用 full NAT 來(lái)實(shí)現(xiàn)了這樣的 traffic control 。因?yàn)檎?qǐng)求發(fā)起方位于K8s cluster邊界之外，如果不把client IP改成Node 1的IP的話，從 Pod B 返回的數(shù)據(jù)會(huì)直接發(fā)給 client 。而 client 端收到這個(gè)數(shù)據(jù)后會(huì)毫不猶豫地丟棄這個(gè)數(shù)據(jù)，因?yàn)樗鼜膩?lái)沒(méi)有向Pod B的 IP 直接發(fā)起過(guò)請(qǐng)求。

（2） ClusterIP

當(dāng)我們選擇 ClusterIP 類型意味著我們所創(chuàng)建 service 的 IP 所能服務(wù)的范圍是在 K8s cluster 內(nèi)部的，故得名 Cluster IP 。下圖展示了在這種類型下，kube-proxy是如何利用 DNAT 來(lái)實(shí)現(xiàn) traffic control 的。在這里可以看到 DNAT 以及 Reverse DNAT 都發(fā)生在同一個(gè)Node上，這個(gè) Node 同時(shí)也運(yùn)行著發(fā)起請(qǐng)求的 Pod 。這也就是說(shuō) ClusterIP 無(wú)法直接對(duì) K8s 邊界外提供服務(wù)。與之相比，上一張圖里客戶端是在 K8s 邊界之外的。

（3）LoadBalancer

當(dāng)我們選擇 LoadBalancer 類型意味我們的本意是想把這個(gè) service 當(dāng)成 load balancer 來(lái)使用。如果你使用的是公有云提供的 K8s 服務(wù)，當(dāng)查看 LoadBalancer 類型的 service 時(shí)，會(huì)明顯地發(fā)現(xiàn) EXTERNAL-IP 欄位不再為 。這個(gè)時(shí)候，云產(chǎn)商會(huì)為你的 LoadBalancer service 分配一個(gè) public IP 地址。別問(wèn)二哥是怎么知道的，二哥可以確定的是這個(gè)價(jià)格不菲，付費(fèi)的產(chǎn)品總是很容易地讓人印象深刻。

lance@2ge:~$ kubectl get svc -n lancehbzhang
NAME                 TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGE
prom-service         NodePort   10.110.115.27   <none>        8080:30000/TCP   14d
lance@2ge:~$ kubectl get svc -n lancehbzhang
NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
front-service       LoadBalancer   10.110.115.27   220.181.38.148   8080:30000/TCP   14d

下圖展示了LoadBalancer service類型下，kube-proxy是如何利用 DNAT 來(lái)實(shí)現(xiàn) traffic control 的。

• 首先看到 LoadBalancer 可以向 K8s cluster 邊界之外提供服務(wù) 。
• LoadBalancer 的實(shí)現(xiàn)依賴于 NodePort service 。
• 整個(gè)過(guò)程既用到 DNAT 又用到了 full NAT 。

（4） ExternalName

優(yōu)雅地略過(guò)。

5、Pod IP

我們繼續(xù)往前走，來(lái)到步驟 ④ 。這是一個(gè)我們都熟悉的領(lǐng)域。每個(gè) Pod 一個(gè) IP 。沒(méi)有 Network Policy 的干預(yù)下，一個(gè) K8s Cluster 內(nèi)，所有 Pod 之間互聯(lián)互通，是一個(gè)位于 L2 的大平層。

我們的 Pod 在完成了它自身需要做的事情之后，需要將一部分工作轉(zhuǎn)交給 service bill.lance.svc.cluster.local 來(lái)負(fù)責(zé)。很顯然，這里需要 DNS 的介入。但且慢，步驟 ③ 那里需要 DNS 嗎?不需要。Ingress 有其它方法以 service 為線索得知它背后的 Pod 地址。在步驟 ⑤ ，Pod 得知了 bill service 的 Cluster-IP ，這就足夠了。步驟 ⑥ 標(biāo)示出了發(fā)起請(qǐng)求的過(guò)程。還記得文首我們提到 bill service 還得借助外部銀行的一個(gè)服務(wù)來(lái)完成它自己的工作嗎?步驟 ⑦ ⑧ 示意了這個(gè)過(guò)程。文章《??當(dāng)從Pod訪問(wèn)百度時(shí)會(huì)用到VTEP嗎??》詳細(xì)講述了當(dāng) Pod 向百度發(fā)起請(qǐng)求時(shí)的過(guò)程。或許你可以從中了解到步驟 ⑧ 這一步所涉及到的過(guò)程。

6、預(yù)告

以上所談及的種種類型的 IP 到底是有誰(shuí)來(lái)負(fù)責(zé)分配的?IP range 又是由誰(shuí)來(lái)決定的?敬請(qǐng)期待二哥后續(xù)文章。