[Kubernetes]說說 Service 與 Ingress

在 Kubernetes 中, Service 有三種對外暴露的方法,可是因爲每一個 Service 都要有一個負載均衡的服務,因此採用 Service 的話,會形成既浪費成本又高的現象.對於用戶來講,我更但願的是,能有一個全局的負載均衡器,而後我只須要經過訪問 URL 就能夠把請求轉發給不一樣的後端 Service ,從而能夠訪問到界面.而不是每一個 Service 都須要負載均衡.
而這,就引出了 Ingress :它就是全局的,爲了代理不一樣後端 Service 而設置的負載均衡服務.

來講個例子:假設我如今有一個站點: https://cafe.example.com ,其中, https://cafe.example.com/coffee ,對應的是"咖啡點餐系統",而 https://cafe.example.com/tea ,對應的則是"茶水點餐系統",而這兩個系統,分別由名叫 coffee 和 tea 這樣兩個 Deployment 來提供服務.
那麼問題來了,我如何使用 Kubernetes 中的 Ingress 來建立一個統一的負載均衡器,從而實現當用戶訪問不一樣的域名時,可以訪問到不一樣的 Deployment 呢?
其實很簡單,寫個 YAML 文件就行了,內容以下:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80
     - path: /tea
        backend:
          serviceName: tea-svc
          servicePort: 80

在上面這個名叫 cafe-ingress.yaml 文件中,最值得關注的就是在 rules 字段,這個字段在 Kubernetes 中,叫作: IngressRule .
IngressRule 的 Key ,就叫作: host ,它必須是一個標準的域名格式的字符串,而不能是 IP 地址.而 host 字段定義的值,就是 Ingress 的入口.也就是說,當用戶訪問 cafe.example.com 時,實際上訪問的就是這個 Ingress 對象,這樣 Kubernetes 就可以使用 IngressRule 來對實際請求進行下一步轉發.
而接下來 IngressRule 規則的定義,則依賴於 path 字段.你能夠看到,在上面的 YAML 文件中,定義了兩個 path ,分別對應 coffee 和 tea 這兩個 Deployment 的 Service (即: coffee-svc 和 tea-svc ).

若是你瞭解過 Nginx 的話,到這兒應該就很容易理解了.所謂 Ingress 對象,其實就是 Kubernetes 項目對"反向代理"的一種抽象,一個 Ingress 對象的主要內容,實際上就是一個"反向代理"服務的配置文件的描述,而這個代理服務對應的轉發規則,就是 IngressRule.
因此這也是爲何在每條 IngressRule 中,須要有一個 host 字段來做爲這條 IngressRule 的入口,還須要有一系列 path 字段來聲明具體的轉發策略.若是你對 Nginx , HAproxy 等項目的配置文件熟悉的話,你會發現其實它們的寫法是一致的.
因此,有了 Ingress 這樣一個統一的抽象, Kubernetes 的用戶就無需關心 Ingress 的具體細節了,在實際使用中,只須要選擇一個具體的 Ingress Controller ,把它部署在 Kubernetes 集羣裏就能夠了.而後接下來的事情,就交給它去作就OK了,你要作的就是去寫相關的 YAML 文件便可.(發現沒有,又下降了使用難度)

不知道你有沒有一個疑問,就是若是個人請求沒有匹配到任何一條 IngressRule ,那麼界面會顯示什麼呢.
你能夠想一想,當你訪問一個網址的時候,它會如何給你反應?沒錯,就是 404 界面.
在 Ingress Controller 中,你也能夠經過 Pod 啓動命令中 -default-backend-service 參數,來設置一條默認規則.這樣,任何匹配失敗的請求,都會被轉發到你指定的 Service ,這樣你就能夠經過部署一個專門的 Pod ,來爲用戶返回自定義的 404 界面了.

以上內容來自我學習<深刻剖析Kubernetes>專欄文章以後的一些看法,有偏頗之處,還望指出.
感謝您的閱讀~