<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          K8s 常用 IP 地址類型知多少

          共 4213字,需瀏覽 9分鐘

           ·

          2022-05-24 14:49

          大家好,我是二哥。

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


          1. 示例介紹


          我們的示例涉及到的主要模塊有:客戶端、L4 Load balancer、Nginx-Ingress、k8s 環(huán)境、外部服務(wù)(https://api.bank.com)。
          客戶端想要訪問的服務(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 。前者的角色從它的名字就可以看出來,而后者用于處理賬單類事務(wù)。當(dāng)然涉及到錢的時(shí)候,總離不開和銀行打交道,所以 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)過原節(jié)點(diǎn),也可能繞過原節(jié)點(diǎn)形成一個(gè)三角傳輸模式,所以這張圖里沒有畫出返回路徑。


          2. L4 LB IP

          ① 客戶端當(dāng)然首先通過 DNS 獲知 FQDN api.2ge.com 的 IP 地址。只不過客戶端不知道的是這個(gè)地址是綁在 L4 load balancer (LB) 上的。這里的 IP 地址是一個(gè) public IP 。如果我們使用的是云服務(wù),那當(dāng)使用它們的 LB 的時(shí)候,會(huì)非常容易地得到一個(gè)固定的 public IP 。
          這里的 LB 工作在 L3/L4 。所謂四層負(fù)載均衡,也就是主要通過包的四層信息( 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)等等。
          簡言之:負(fù)載均衡的兩大職責(zé)是“選擇誰來處理用戶請(qǐng)求”和“將用戶請(qǐng)求轉(zhuǎn)發(fā)過去”。
          當(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 直接通過 public IP 暴露在 internet 上呢?答案當(dāng)然是可以的。只是 L4 LB 只是單純地轉(zhuǎn)發(fā)包,且這個(gè)過程不需要和上下游建立連接。相比于 Nginx ,它的抗負(fù)載能力強(qiáng)、性能高(能相對(duì)靠近 F5 或 A10 硬件性能),對(duì)內(nèi)存和cpu資源消耗比較低。
          從這里我們也可以看出來多級(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


          ③ 既然說 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ā),這些多出來的步驟顯然笨重了許多。
          但這個(gè)世界上的東西沒有絕對(duì)的優(yōu)點(diǎn)和缺點(diǎn)。當(dāng) ③ 得知了訪問所請(qǐng)求的 path 之后,也便對(duì)通信內(nèi)容有了更多的了解,當(dāng)然也就有了更多的話語權(quán),自然就能做更智能、更復(fù)雜的流量監(jiān)控。比如我們可以以 REST API 為粒度來統(tǒng)計(jì)訪問流量、延遲、錯(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 類型。


          4.1 NodePort

          當(dāng)我們選擇 NodePort 類型意味著我們可以用 Node 自身的 IP 地址搭配在 Node 上所開啟的端口訪問該服務(wù)。
          下圖展示了在這種類型下,客戶端通過向 Node1 的 IP 地址(端口未畫出)發(fā)起請(qǐng)求,但最終由位于 Node2上的 Pod B 提供服務(wù)的流程。
          圖中 kube-proxy 利用 full NAT 來實(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)樗鼜膩頉]有向Pod B的 IP 直接發(fā)起過請(qǐng)求。


          4.2 ClusterIP

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


          二哥在文章《綜合題:一個(gè)請(qǐng)求如何從service到達(dá)Pod ?》里詳細(xì)分析了這種類似的 service 請(qǐng)求是如何處理的。

          4.3 LoadBalancer

          當(dāng)我們選擇 LoadBalancer 類型意味我們的本意是想把這個(gè) service 當(dāng)成 load balancer 來使用。
          如果你使用的是公有云提供的 K8s 服務(wù),當(dāng)查看 LoadBalancer 類型的 service 時(shí),會(huì)明顯地發(fā)現(xiàn) EXTERNAL-IP 欄位不再為 ? 。這個(gè)時(shí)候,云產(chǎn)商會(huì)為你的 LoadBalancer service 分配一個(gè) public IP 地址。別問二哥是怎么知道的,二哥可以確定的是這個(gè)價(jià)格不菲,付費(fèi)的產(chǎn)品總是很容易地讓人印象深刻。
          lance@2ge:~$ kubectl get svc -n lancehbzhangNAME                 TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)         AGEprom-service         NodePort   10.110.115.27           8080:30000/TCP   14d
          lance@2ge:~$ kubectl get svc -n lancehbzhangNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEfront-service LoadBalancer 10.110.115.27 220.181.38.148 8080:30000/TCP 14d

          下圖展示了LoadBalancer service類型下,kube-proxy是如何利用 DNAT 來實(shí)現(xiàn) traffic control 的。
          • 首先看到 LoadBalancer 可以向 K8s cluster 邊界之外提供服務(wù) 。
          • LoadBalancer 的實(shí)現(xiàn)依賴于 NodePort service 。
          • 整個(gè)過程既用到 DNAT 又用到了 full NAT 。


          4.4 ExternalName

          優(yōu)雅地略過。

          5. Pod IP


          我們繼續(xù)往前走,來到步驟 ④ 。這是一個(gè)我們都熟悉的領(lǐng)域。每個(gè) Pod 一個(gè) IP 。沒有 Network Policy 的干預(yù)下,一個(gè) K8s Cluster 內(nèi),所有 Pod 之間互聯(lián)互通,是一個(gè)位于 L2 的大平層。
          我們的 Pod 在完成了它自身需要做的事情之后,需要將一部分工作轉(zhuǎn)交給 service bill.lance.svc.cluster.local 來負(fù)責(zé)。很顯然,這里需要 DNS 的介入。
          但且慢,步驟 ③ 那里需要 DNS 嗎?不需要。Ingress 有其它方法以 service 為線索得知它背后的 Pod 地址。
          在步驟 ⑤ ,Pod 得知了 bill service 的 Cluster-IP ,這就足夠了。步驟 ⑥ 標(biāo)示出了發(fā)起請(qǐng)求的過程。
          還記得文首我們提到 bill service 還得借助外部銀行的一個(gè)服務(wù)來完成它自己的工作嗎?步驟 ⑦ ⑧ 示意了這個(gè)過程。
          文章《當(dāng)從Pod訪問百度時(shí)會(huì)用到VTEP嗎》詳細(xì)講述了當(dāng) Pod 向百度發(fā)起請(qǐng)求時(shí)的過程?;蛟S你可以從中了解到步驟 ⑧ 這一步所涉及到的過程。

          6. 預(yù)告


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

          以上就是本文的全部內(nèi)容。碼字不易,畫圖更難。喜歡本文的話請(qǐng)幫忙轉(zhuǎn)發(fā)或點(diǎn)擊“在看”。您的舉手之勞是對(duì)二哥莫大的鼓勵(lì)。謝謝!
          瀏覽 55
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  久久AV影片| 色哟哟国产精品 | 日日色综合 | 狂野欧美做受XXXX高潮 | 大鸡吧视频免费在线看 |