Ingress 這個(gè)老6，結(jié)合nodeport和ClusterIp兩種服務(wù)類型，你在引流這一塊玩的花啊。 入口一夫當(dāng)關(guān)，對(duì)內(nèi)如魚得水。

本文是有態(tài)度馬甲的第185篇原創(chuàng)。

本文記錄了k8s中核心對(duì)象Ingress的產(chǎn)生背景和實(shí)現(xiàn)機(jī)制。

我們都知道k8s Service是一種將Pods通過網(wǎng)絡(luò)暴露出來(lái)的抽象，每個(gè)服務(wù)定義了一組有關(guān)Pod的端點(diǎn)， Service有幾種類型

• ClusterIP： 默認(rèn)，以集群內(nèi)Ip的形式提供集群內(nèi)的可訪問性
• NodePort：在每個(gè)節(jié)點(diǎn)的靜態(tài)端口上對(duì)外暴露了服務(wù)
• Loadbalancer： 外部負(fù)載均衡器

這不明擺了，常規(guī)的對(duì)外暴露服務(wù)的方式只有NodePort嗎？

NodePort類型建立在ClusterIP服務(wù)類型之上， 意味著你創(chuàng)建了NodePort類型服務(wù)，k8s自動(dòng)創(chuàng)建了ClusterIP 服務(wù)。

外部客戶端---> 任意節(jié)點(diǎn)（NodePort）---> ClusterIP服務(wù)---> Pod

有幾個(gè)缺陷：

• NodePort形式的服務(wù) 沒有跨節(jié)點(diǎn)的負(fù)載均衡能力， 有的節(jié)點(diǎn)忙著導(dǎo)流，有的閑得蛋疼
• 能暴露的服務(wù)數(shù)量受限于節(jié)點(diǎn)的可用端口
• 這姑且不算缺陷吧： 引流方式基于節(jié)點(diǎn)端口，位于osi網(wǎng)絡(luò)模型的4層， 人類感知不明顯。

Ingress號(hào)稱是一種智能路由，表象上Ingress從集群外部將HTTP和HTTPS路由引流到k8s集群中的Service。

一個(gè)典型的數(shù)據(jù)流如上圖

曾幾何時(shí)，我以為Ingress是新開天辟地的網(wǎng)絡(luò)引流方案。

后面等我深究一丟丟，發(fā)現(xiàn)k8s Ingress 其實(shí)是個(gè)老6， 它對(duì)外暴露服務(wù)的方式其實(shí)很賊，還是現(xiàn)成技能的積木。

Ingress 本質(zhì)上是先在集群內(nèi)產(chǎn)生了負(fù)載均衡服務(wù)(nginx pod), 這個(gè)k8s服務(wù)在集群內(nèi)與其他服務(wù)必然可以互訪。

然后咋們目標(biāo)不是要對(duì)外暴露服務(wù)嗎？ 那我這個(gè)Ingress Nginx服務(wù)就作為一個(gè)流量入口，我這個(gè)服務(wù)還使用NodePort形式對(duì)外暴露服務(wù)， 對(duì)內(nèi)通過nginx天生的路由能力來(lái)引流到后端的Service。

下面是Ingress-nginx的流程圖:

注意流量從 client---> nginx pod ---> service Pod,

Ingress記錄并監(jiān)聽了注冊(cè)到Ingress上服務(wù)的路由規(guī)則，Ingress-Nginx Controller是本次業(yè)務(wù)的聲明式核心控制器，確保產(chǎn)生滿足這一規(guī)則的NodePort類型的nginx服務(wù), Ingress nginx本身不能解決節(jié)點(diǎn)間負(fù)載均衡問題，注意還需前置負(fù)載提供跨節(jié)點(diǎn)負(fù)載均衡能力。

---

我們找個(gè)demo快速驗(yàn)證一下吧。

k8s ingress官方 給了一個(gè)通過Ingress引流到"hello world“ 這樣的服務(wù)，但是它的服務(wù)竟然采用了NodePort形式，這都NodePort了，還要你Ingress作甚。

我的Demo是以默認(rèn)的ClusterIP形式快速啟動(dòng)了Nginx服務(wù)，

已經(jīng)顯示nginx-svc是 ClusterIP類型的服務(wù)。

aladdin@bogon ~ % kubectl get  svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1      <none>        443/TCP   7d
nginx-svc    ClusterIP   10.103.46.57   <none>        80/TCP    24h

之后使用Ingress配置通過host:hello.nginx.com路由到nginx-svc服務(wù)：

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-ingress
    spec:
      rules:
      - host: hello.nginx.com
        http:
          paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-svc
                port:
                  number: 80

產(chǎn)生一個(gè)Ingress核心對(duì)象

    aladdin@bogon ~ % kubectl get  ingress
    NAME              CLASS   HOSTS             ADDRESS        PORTS   AGE
    example-ingress   nginx   hello.nginx.com   192.168.58.2   80      24h

準(zhǔn)備工作就做完了。

啟動(dòng)minikube tunnel, 然后在新的終端執(zhí)行curl 127.0.0.1 -H "host:hello.nginx.com" 你會(huì)看到nginx服務(wù)的Welcome to nginx!輸出。

That's All, Ingress 就是如此暴露服務(wù)引流的.

---

Ingress相關(guān)的核心對(duì)象默認(rèn)被安裝在Ingress-nginx命名空間下，我們接著驗(yàn)證Ingress架構(gòu)圖中出現(xiàn)的組件:

上圖中出現(xiàn)了兩種核心對(duì)象：

• Deployment/Pod： ingress-nginx-controller-56d7c84fd4-znrvq其實(shí)就是Nginx Pod
• Service： 以NodePort形式對(duì)外暴露的ingress-nginx-controller服務(wù)

根據(jù)我們的猜想：

這個(gè)Nginx Pod受ingress-nginx-controller服務(wù)(NodePort)控制對(duì)外暴露路由服務(wù)， 對(duì)內(nèi)引流到backend Service。

驗(yàn)證如下：

---

Ingress-nginx分為兩大塊： Ingress規(guī)則和Ingress-nginx controller Service，

兩者配合一舉解決了NodePort暴露服務(wù)的一些缺陷， 通過Ingress暴露服務(wù)既能有效節(jié)約節(jié)點(diǎn)端口，又有負(fù)載均衡能力（搭配前置負(fù)載），又是廣大碼農(nóng)喜聞樂見的7層協(xié)議， 悠哉快哉。

但是歸根到底，Ingress-nginx底層還是NodePort服務(wù)和ClusterIP服務(wù)的積木組合， 實(shí)在是高啊。