Kubernetes學習之路（十五）之Ingress和Ingress Controller

目錄

• 一、什么是Ingress？
  • 1、Pod 漂移問題
  • 2、端口管理問題
  • 3、域名分配及動態更新問題
• 二、如何創建Ingress資源
• 三、Ingress資源類型
  • 1、單Service資源型Ingress
• 四、Ingress Nginx部署
  • 1、部署Ingress controller
  • 2、部署后端服務
  • 3、部署ingress-nginx service
  • 4、部署ingress
• 四、增加tomcat服務
• 四、構建TLS站點

一、什么是Ingress？

從前面的學習，我們可以了解到Kubernetes 暴露服務的方式目前只有三種：LoadBlancer Service、ExternalName、NodePort Service、Ingress；而我們需要將集群內服務提供外界訪問就會產生以下幾個問題：

1、Pod 漂移問題

Kubernetes 具有強大的副本控制能力，能保證在任意副本（Pod）掛掉時自動從其他機器啟動一個新的，還可以動態擴容等，通俗地說，這個 Pod 可能在任何時刻出現在任何節點上，也可能在任何時刻死在任何節點上；那么自然隨着 Pod 的創建和銷毀，Pod IP 肯定會動態變化；那么如何把這個動態的 Pod IP 暴露出去？這里借助於 Kubernetes 的 Service 機制，Service 可以以標簽的形式選定一組帶有指定標簽的 Pod，並監控和自動負載他們的 Pod IP，那么我們向外暴露只暴露 Service IP 就行了；這就是 NodePort 模式：即在每個節點上開起一個端口，然后轉發到內部 Pod IP 上，如下圖所示：
此時的訪問方式：http://nodeip:nodeport/

2、端口管理問題

采用 NodePort 方式暴露服務面臨問題是，服務一旦多起來，NodePort 在每個節點上開啟的端口會及其龐大，而且難以維護；這時，我們可以能否使用一個Nginx直接對內進行轉發呢？眾所周知的是，Pod與Pod之間是可以互相通信的，而Pod是可以共享宿主機的網絡名稱空間的，也就是說當在共享網絡名稱空間時，Pod上所監聽的就是Node上的端口。那么這又該如何實現呢？簡單的實現就是使用 DaemonSet 在每個 Node 上監聽 80，然后寫好規則，因為 Nginx 外面綁定了宿主機 80 端口（就像 NodePort），本身又在集群內，那么向后直接轉發到相應 Service IP 就行了，如下圖所示：

3、域名分配及動態更新問題

從上面的方法，采用 Nginx-Pod 似乎已經解決了問題，但是其實這里面有一個很大缺陷：當每次有新服務加入又該如何修改 Nginx 配置呢？？我們知道使用Nginx可以通過虛擬主機域名進行區分不同的服務，而每個服務通過upstream進行定義不同的負載均衡池，再加上location進行負載均衡的反向代理，在日常使用中只需要修改nginx.conf即可實現，那在K8S中又該如何實現這種方式的調度呢？？？

假設后端的服務初始服務只有ecshop，后面增加了bbs和member服務，那么又該如何將這2個服務加入到Nginx-Pod進行調度呢？總不能每次手動改或者Rolling Update 前端 Nginx Pod 吧！！此時 Ingress 出現了，如果不算上面的Nginx，Ingress 包含兩大組件：Ingress Controller 和 Ingress。

Ingress 簡單的理解就是你原來需要改 Nginx 配置，然后配置各種域名對應哪個 Service，現在把這個動作抽象出來，變成一個 Ingress 對象，你可以用 yaml 創建，每次不要去改 Nginx 了，直接改 yaml 然后創建/更新就行了；那么問題來了：”Nginx 該怎么處理？”

Ingress Controller 這東西就是解決 “Nginx 的處理方式” 的；Ingress Controoler 通過與 Kubernetes API 交互，動態的去感知集群中 Ingress 規則變化，然后讀取他，按照他自己模板生成一段 Nginx 配置，再寫到 Nginx Pod 里，最后 reload 一下，工作流程如下圖：

實際上Ingress也是Kubernetes API的標准資源類型之一，它其實就是一組基於DNS名稱（host）或URL路徑把請求轉發到指定的Service資源的規則。用於將集群外部的請求流量轉發到集群內部完成的服務發布。我們需要明白的是，Ingress資源自身不能進行“流量穿透”，僅僅是一組規則的集合，這些集合規則還需要其他功能的輔助，比如監聽某套接字，然后根據這些規則的匹配進行路由轉發，這些能夠為Ingress資源監聽套接字並將流量轉發的組件就是Ingress Controller。

PS：Ingress 控制器不同於Deployment 控制器的是，Ingress控制器不直接運行為kube-controller-manager的一部分，它僅僅是Kubernetes集群的一個附件，類似於CoreDNS，需要在集群上單獨部署。

二、如何創建Ingress資源

Ingress資源時基於HTTP虛擬主機或URL的轉發規則，需要強調的是，這是一條轉發規則。它在資源配置清單中的spec字段中嵌套了rules、backend和tls等字段進行定義。如下示例中定義了一個Ingress資源，其包含了一個轉發規則：將發往myapp.magedu.com的請求，代理給一個名字為myapp的Service資源。

apiVersion: extensions/v1beta1		
kind: Ingress		
metadata:			
  name: ingress-myapp   
  namespace: default     
  annotations:          
    kubernetes.io/ingress.class: "nginx"
spec:     
  rules:   
  - host: myapp.magedu.com   
    http:
      paths:       
      - path:       
        backend:    
          serviceName: myapp
          servicePort: 80

Ingress 中的spec字段是Ingress資源的核心組成部分，主要包含以下3個字段：

• rules