大家好，我是二哥。

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

1、示例介紹

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

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

2、L4 LB IP

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

3、Ingress IP

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

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

4、service IP

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

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

（1） NodePort

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

（2） ClusterIP

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

（3）LoadBalancer

當我們選擇 LoadBalancer 類型意味我們的本意是想把這個 service 當成 load balancer 來使用。如果你使用的是公有云提供的 K8s 服務，當查看 LoadBalancer 類型的 service 時，會明顯地發現 EXTERNAL-IP 欄位不再為 。這個時候，云產商會為你的 LoadBalancer service 分配一個 public IP 地址。別問二哥是怎么知道的，二哥可以確定的是這個價格不菲，付費的產品總是很容易地讓人印象深刻。

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 來實現 traffic control 的。

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

（4） ExternalName

優雅地略過。

5、Pod IP

我們繼續往前走，來到步驟 ④ 。這是一個我們都熟悉的領域。每個 Pod 一個 IP 。沒有 Network Policy 的干預下，一個 K8s Cluster 內，所有 Pod 之間互聯互通，是一個位于 L2 的大平層。

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

6、預告

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