6張圖帶你學懂 Kubernetes Ingress
Kubernetes Ingress 只是 Kubernetes 中的一個普通資源對象，需要一個對應的 Ingress 控制器來解析 Ingress 的規則，暴露服務到外部，比如 ingress-nginx，本質上來說它只是一個 Nginx Pod，然后將請求重定向到其他內部（ClusterIP）服務去，這個 Pod 本身也是通過 Kubernetes 服務暴露出去，最常見的方式是通過 LoadBalancer 來實現的。
同樣本文我們希望用一個簡單清晰的概述，讓你來了解 Kubernetes Ingress 背后的東西，讓你更容易理解使用的 Ingress。
我們可以使用 Ingress 來使內部服務暴露到集群外部去，它為你節省了寶貴的靜態 IP，因為你不需要聲明多個 LoadBalancer 服務了，此次，它還可以進行更多的額外配置。下面我們通過一個簡單的示例來對 Ingress 進行一些說明吧。
簡單 HTTP server
首先，我們先回到容器、Kubernetes 之前的時代。之前我們更多會使用一個（Nginx）HTTP server 來托管我們的服務，它可以通過 HTTP 協議接收到一個特定文件路徑的請求，然后在文件系統中檢查這個文件路徑，如果存在則就返回即可。
例如，在 Nginx 中，我們可以通過下面的配置來實現這個功能。
- location /folder {
- root /var/www/;
- index index.html;
- }
除了上面提到的功能之外，我們可以當 HTTP server 接收到請求后，將該請求重定向到另一個服務器（意味著它作為代理）去，然后將該服務器的響應重定向到客戶端去。對于客戶端來說，什么都沒有改變，接收到的結果仍然還是請求的文件（如果存在的話）。
同樣如果在 Nginx 中，重定向可以配置成下面的樣子：
- location /folder {
- proxy_pass http://second-nginx-server:8000;
- }
這意味著 Nginx 可以從文件系統中提供文件，或者通過代理將響應重定向到其他服務器并返回它們的響應。
簡單的 Kubernetes 示例
使用 ClusterIP 服務
在 Kubernetes 中部署應用后，我們應該先去了解 Kubernetes Service 服務（前文中講解的）。比如我們有兩個 worker 節點，有兩個服務 service-nginx 和 service-python，它們指向不同的 pods。這兩個服務沒有被調度到任何特定的節點上，也就是在任何節點上都有可能，如下圖所示：
在集群內部我們可以通過他們的 Service 服務來請求到 Nginx pods 和 Python pods 上去，現在我們想讓這些服務也能從集群外部進行訪問，按照前文提到的我們就需要將這些服務轉換為 LoadBalancer 服務。
使用 LoadBalancer 服務
當然使用 LoadBalancer 服務的前提是我們的 Kubernetes 集群的托管服務商要能支持才行，如果支持我們可以將上面的 ClusterIP 服務轉換為 LoadBalancer 服務，可以創建兩個外部負載均衡器，將請求重定向到我們的節點 IP，然后重定向到內部的 ClusterIP 服務。
我們可以看到兩個 LoadBalancers 都有自己的 IP，如果我們向 LoadBalancer 22.33.44.55 發送請求，它請被重定向到我們的內部的 service-nginx 服務去。如果發送請求到 77.66.55.44，它將被重定向到我們的內部的 service-python 服務。
這個確實很方便，但是要知道 IP 地址是比較稀有的，而且價格可不便宜。想象下我們 Kubernetes 集群中不只是兩個服務，有很多的話，我們為這些服務創建 LoadBalancers 成本是不是就成倍增加了。那么是否有另一種解決方案可以讓我們只使用一個 LoadBalancer 就可以把請求轉發給我們的內部服務呢？我們先通過手動（非 Kubernetes）的方式來探討下這個問題。
手動配置 Nginx 代理服務
我們知道 Nginx 可以作為一個代理使用，所以我們可以很容易想到運行一個 Nginx 來代理我們的服務。如下圖所示，我們新增了一個名為 service-nginx-proxy 的新服務，它實際上是我們唯一的一個 LoadBalancer 服務。service-nginx-proxy 仍然會指向一個或多個 Nginx-pod-endpoints（為了簡單沒有在圖上標識），之前的另外兩個服務轉換為簡單的 ClusterIP 服務了。
可以看到我們只分配了一個 IP 地址為 11.22.33.44 的負載均衡器，對于不同的 http 請求路徑我們用黃色來進行標記，他們的目標是一致的，只是包含的不同的請求 URL。service-nginx-proxy 服務會根據請求的 URL 來決定他們應該將請求重定向到哪個服務去。在上圖中我們有兩個背后的服務，分別用紅色和藍色進行了標記，紅色會重定向到 service-nginx 服務，藍色重定向到 service-python 服務。對應的 Nginx 代理配置如下所示：
- location /folder {
- proxy_pass http://service-nginx:3001;
- }
- location /other {
- proxy_pass http://service-python:3002;
- }
只是目前我們需要去手動配置 service-nginx-proxy 服務，比如新增了一個請求路徑需要路由到其他服務去，我們就需要去重新配置 Nginx 的配置讓其生效，但是這個確實是一個可行的解決方案，只是有點麻煩而已。而 Kubernetes Ingress 就是為了讓我們的配置更加容易、更加智能、更容易管理出現的，所以在 Kubernetes 集群中我們會用 Ingress 來代替上面的手動配置的方式將服務暴露到集群外去。
使用 Kubernetes Ingress
現在我們將上面手動配置代理的方式轉換為 Kubernetes Ingress 的方式，如下圖所示，我們只是使用了一個預先配置好的 Nginx（Ingress），它已經為我們做了所有的代理重定向工作，這為我們節省了大量的手動配置工作了。
這其實就已經說明了 Kubernetes Ingress 是什么，下面讓我們來看看一些配置實例吧。
安裝 Ingress 控制器
Ingress 只是 Kubernetes 的一種資源對象而已，在這個資源中我們可以去配置我們的服務路由規則，但是要真正去實現識別這個 Ingress 并提供代理路由功能，還需要安裝一個對應的控制器才能實現。
- $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml
- $ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yaml
使用下面的命令，可以看到安裝在命名空間 ingress-nginx 中的 k8s 資源。
我們可以看到一個正常的 LoadBalancer 服務，有一個外部 IP 和一個所屬的 pod，我們可以使用命令 kubectl exec 進入該 pod，里面包含一個預配置的 Nginx 服務器。
其中的 nginx.conf 文件就包含各種代理重定向設置和其他相關配置。
Ingress 配置示例
我們所使用的 Ingress yaml 例子可以是這樣的。
- # just example, not tested
- apiVersion: networking.k8s.io/v1beta1
- kind: Ingress
- metadata:
- annotations:
- kubernetes.io/ingress.class: nginx
- namespace: default
- name: test-ingress
- spec:
- rules:
- - http:
- paths:
- - path: /folder
- backend:
- serviceName: service-nginx
- servicePort: 3001
- - http:
- paths:
- - path: /other
- backend:
- serviceName: service-python
- servicePort: 3002
和其他資源對象一樣，通過 kubectl create -f ingress.yaml 來創建這個資源對象即可，創建完成后這個 Ingress 對象會被上面安裝的 Ingress 控制器轉換為對應的 Nginx 配置。
如果你的一個內部服務，即 Ingress 應該重定向到的服務，是在不同的命名空間里，怎么辦？因為我們定義的 Ingress 資源是命名空間級別的。在 Ingress 配置中，只能重定向到同一命名空間的服務。如果你定義了多個 Ingress yaml 配置，那么這些配置會被一個單一的Ingress 控制器合并成一個 Nginx 配置。也就是說所有的人都在使用同一個 LoadBalancer IP。
配置 Ingress Nginx
有時候我們需要對 Ingress Nginx 進行一些微調配置，我們可以通過 Ingress 資源對象中的 annotations 注解來實現，比如我們可以配置各種平時直接在 Nginx 中的配置選項。
- kind: Ingress
- metadata:
- name: ingress
- annotations:
- kubernetes.io/ingress.class: nginx
- nginx.ingress.kubernetes.io/proxy-connect-timeout: '30'
- nginx.ingress.kubernetes.io/proxy-send-timeout: '500'
- nginx.ingress.kubernetes.io/proxy-read-timeout: '500'
- nginx.ingress.kubernetes.io/send-timeout: "500"
- nginx.ingress.kubernetes.io/enable-cors: "true"
- nginx.ingress.kubernetes.io/cors-allow-methods: "*"
- nginx.ingress.kubernetes.io/cors-allow-origin: "*"
- ...
此外也可以做更細粒度的規則配置，如下所示：
- nginx.ingress.kubernetes.io/configuration-snippet: |
- if ($host = 'www.qikqiak.com' ) {
- rewrite ^ https://qikqiak.com$request_uri permanent;
- }
這些注釋都將被轉換成 Nginx 配置，你可以通過手動連接(kubectl exec)到 nginx pod 中檢查這些配置。關于 ingress-nginx 更多的配置使用可以參考官方文檔相關說明：
- https://github.com/kubernetes/ingress-nginx/tree/master/docs/user-guide/nginx-configuration
- https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#lua-resty-waf
查看 ingress-nginx 日志
要排查問題，通過查看 Ingress 控制器的日志非常有幫助。
使用 Curl 測試
如果我們想測試 Ingress 重定向規則，最好使用 curl -v [yourhost.com](http://yourhost.com) 來代替瀏覽器，可以避免緩存等帶來的問題。
重定向規則
在本文的示例中我們使用 /folder 和 /other/directory 等路徑來重定向到不同的服務，此外我們也可以通過主機名來區分請求，比如將 api.myurl.com 和 site.myurl.com 重定向到不同的內部 ClusterIP 服務去。
- apiVersion: networking.k8s.io/v1beta1
- kind: Ingress
- metadata:
- name: simple-fanout-example
- spec:
- rules:
- - host: api.myurl.com
- http:
- paths:
- - path: /foo
- backend:
- serviceName: service1
- servicePort: 4200
- - path: /bar
- backend:
- serviceName: service2
- servicePort: 8080
- - host: website.myurl.com
- http:
- paths:
- - path: /
- backend:
- serviceName: service3
- servicePort: 3333
SSL/HTTPS
可能我們想讓網站使用安全的 HTTPS 服務，Kubernetes Ingress 也提供了簡單的 TLS 校驗，這意味著它會處理所有的 SSL 通信、解密/校驗 SSL 請求，然后將這些解密后的請求發送到內部服務去。
如果你的多個內部服務使用相同（可能是通配符）的 SSL 證書，這樣我們就只需要在 Ingress 上配置一次，而不需要在內部服務上去配置，Ingress 可以使用配置的 TLS Kubernetes Secret 來配置 SSL 證書。
- apiVersion: networking.k8s.io/v1beta1
- kind: Ingress
- metadata:
- name: tls-example-ingress
- spec:
- tls:
- - hosts:
- - sslexample.foo.com
- secretName: testsecret-tls
- rules:
- - host: sslexample.foo.com
- http:
- paths:
- - path: /
- backend:
- serviceName: service1
- servicePort: 80
不過需要注意的是如果你在不同的命名空間有多個 Ingress 資源，那么你的 TLS secret 也需要在你使用的 Ingress 資源的所有命名空間中可用。
總結
這里我們簡單介紹了 Kubernetes Ingress 的原理，簡單來說：它不過是一種輕松配置 Nginx 服務器的方法，它可以將請求重定向到其他內部服務去。這為我們節省了寶貴的靜態 IP 和 LoadBalancers 資源。
另外需要注意的是還有其他的 Kubernetes Ingress 類型，它們內部沒有設置 Nginx 服務，但可能使用其他代理技術，一樣也可以實現上面的所有功能。
