大家好，我是二哥。

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

1、示例介紹

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

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

2、L4 LB IP

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

3、Ingress IP

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

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

4、service IP

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

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

（1） NodePort

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

（2） ClusterIP

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

（3）LoadBalancer

當我們選擇 LoadBalancer 類型意味我們的本意是想把這個 service 當成 load balancer 來使用。如果你使用的是公有云提供的 K8s 服務(wù)，當查看 LoadBalancer 類型的 service 時，會明顯地發(fā)現(xiàn) EXTERNAL-IP 欄位不再為 。這個時候，云產(chǎn)商會為你的 LoadBalancer service 分配一個 public IP 地址。別問二哥是怎么知道的，二哥可以確定的是這個價格不菲，付費的產(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 來實現(xiàn) traffic control 的。

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

（4） ExternalName

優(yōu)雅地略過。

5、Pod IP

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

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

6、預(yù)告

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