在 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>專欄文章之后的一些見解,有偏頗之處,還望指出.
感謝您的閱讀~