Ingress and Ingress Controller

Service 和Pod的IP地址都只能在cluster內部使用，無法穿過Edge Router 來達成cluster內外通訊, 雖然可以用Service的NodePort或LoadBalancer將外部流量導入,但Service只有四層流量轉發, 可用的只有傳輸層負載均衡機制, 於是才設計了Ingress。
Ingerss 是一組基於DNS名稱或URL路徑把外部請求流量轉發到內部指定Service的規則, 它必須搭配Ingress Controller才能進行目標對象匹配。Ingress Controller 並不直接運行在kube-controller-manager （和deployment controller 不同）, Ingress Controller類似CoreDNS, 需要單獨部署。

• Ingress Controller 本身也是一個Pod
• 可以由具有反向代理(HTTP/HTTPS)功能的服務實現, ex: Nginx
• 需要一個Service 輔助識別關聯的Pod, 又可以繞過Service直接把流量轉發到後端的Pod上, 如圖所示 Ingress Controller 經由 api.ilinux.io 規則的定義將流量調度到Pod3或Pod4。

YAML 配置

Ingress 是基於HTTP虛擬主機或URL的轉發規則, 它在spec中可以配置字段rules, backend, tls...等, 它會在YAML中用annotations來分辨Ingress Controller 的類別。

  apiVersion: extensions/v1beta1
  kind: Ingress
  metadata:
    name: ingress-demo
    annotations:
      kubernetes.io/ingress.class: "nginx"
  spec:
    rules:
    - host: www.ilinux.io
      http:
        paths:
        - backend:
            serviceName: svc-demo
            servicePort: 80

• rules <Object>: 定義當前的轉發規則, 沒有匹配到任何規則的都會轉發到backend定義的默認對象, 必填字段serviceName, servicePort

• backend <Object>: 用於讓負載均衡器指定一個默認的後端對象, rules 和 backend要擇一設定

• tls <Object>: 支援port:443流量轉發, 必填字段hosts-TLS字符串列表, 選填字段 secretName- 引用SSL的secret名稱

Ingress 類型

1. 單服務Ingress
   NodePort, LoadBalancer也可以實現暴露單個服務, 至於Ingress則是只要指定default backend 即可達成。

     apiVersion: extensions/v1beta1
     kind: Ingress
     metadata:
       name: ingress-demo
     spec:
       backend:
         serviceName: svc-demo
         servicePort: 80
   

2. 簡單分列-基於URL路徑進行流量分發
   將對外開放的url流量轉發到內部的Service。

     apiVersion: extensions/v1beta1
     kind: Ingress
     metadata:
       name: ingress-demo
       annotations:
         ingress.kubernetes.io/rewrite-target: /
     spec:
       rules:
       - host: www.ilinux.io
         http:
          paths:
          - path: /wap
            backend:
              serviceName: wap
              servicePort: 80
          - path: /api
            backend:
              serviceName: api
              servicePort: 80
   

3. 基於主機名稱的虛擬主機託管
   將多個FQDN主機解析到同一個地址之後再根據Host Header進行轉發到內部Service。

     apiVersion: extensions/v1beta1
     kind: Ingress
     metadata:
       name: test
     spec:
       rules:
       - host: api.ik8s.io
         http:
           paths:
           - backend:
               serviceName: api
               servicePort: 80
       - host: api.ik8s.io
         http:
           paths:
           - backend:
               serviceName: wap
               servicePort: 80
   

4. TLS
   用於HTTPS發布Service

     apiVersion: extensions/v1beta1
     kind: Ingress
     metadata:
       name: no-rules-map
     spec:
       tls:
       - secretName: ikubernetesSecret
       backend:
         serviceName: homesite
         servicePort: 80
   

補充: TCP負載均衡器和HTTP(S)負載均衡器

• TCP負載均衡器
  工作於傳輸層的調度器, 支援調度HTTP, MYSQL等應用, 無論是iptables或是ipvs的Service都是配置於Linux內核的Netfilter上面,
  其無法做到卸載HTTPS的SSL也不支援基於URL的請求調度機制

• HTTP(S)負載均衡器
  工作於應用層的負載均衡機制, 可以根據環境作出更好的調度決策, 可以自訂URL映射和TLS卸載, 且支援對後端服務健康狀態檢查的機制。

今日小結

今天的Ingress比起Service花了比較多的時間去理解跟查資料, 讀到這裡再回頭看一下同事們部署在K8s上面的設定, 已經看得懂也聽得懂了, 明天繼續吧