kubernetes Ingress

一、Ingress

在Kubernetes中，服務和Pod的IP地址僅能夠在集羣網絡內部使用，對於集羣外的應用是不可見的。爲了使外部的應用可以訪問集羣內的服務，在Kubernetes中能夠經過NodePort和LoadBalancer這兩種類型的服務，或者使用Ingress。Ingress本質是經過http代理服務器將外部的http請求轉發到集羣內部的後端服務。Kubernetes目前支持GCE和nginx控制器；另外，F5網絡爲Kubernetes提供了F5 Big-IP控制器。經過Ingress，外部應用訪問羣集內容服務的過程以下所示。

Ingress控制器一般會使用負載均衡器來負責實現Ingress，儘管它也能夠經過配置邊緣路由器或其它前端以HA方式處理流量。

二、Ingress配置文件

下面是Ingress YAML配置文件的示例：

apiVersion: extensions/v1beta1 kind: Ingress metadata:  name: test-ingress  annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec:  rules:  - http:  paths:  - path: /testpath  backend:  serviceName: test  servicePort: 80

• 1-6行：Ingress YAML文件中的1-6行與其它的Kubernetes配置文件同樣，須要apiVersion, kind和metadata字段。此示例定義了名稱爲test-ingress的Ingress。
• 7-9行：Ingress規格具備配置負載均衡器或代理服務器所需的全部信息。最重要的是，它包含與全部傳入請求相匹配的規則列表。目前，Ingress資源僅支持http規則。
• 10-11行：每一個http規則都包含如下信息：一個主機（例如：foo.ba.com，在這個例子中爲*），一個路徑列表（例如：/testpath），每一個路徑都有一個相關的後端（test：80）。在負載均衡器將業務引導到後端以前，主機和路徑都必須匹配傳入請求的內容。
• 12-14行：後端是服務:端口（test：80）的組合。Ingress流量一般被直接發送到與後端相匹配的端點。

三、Ingress類型

3.1 代理單一服務

Kubernetes可使用LoadBalancer和NodePort類型的服務暴露服務，也能夠經過一個Ingress來實現。下面是名稱爲test-ingress的Ingress YAML文件，它將對外代理名稱爲testsvc的服務。

apiVersion: extensions/v1beta1 kind: Ingress metadata:  name: single-ingress  annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec:  rules:  - host: foo.bar.com http:  paths:  - path: /foo backend:  serviceName: s1  servicePort: 80

經過kubectl create -f建立上述的Ingress，在建立後能夠經過kubectl get ing的命令獲取Ingress的列表信息：

$ kubectl get ing 

NAME RULE BACKEND ADDRESS

single-ingress –s1:80 107.178.254.228

3.2 代理多個服務

如前所述，在kubernetes 中Pod的IP地址只能對羣集內的其它的應用可見。所以，若是須要接受集羣外部的流量，並將其代理到集羣中後端服務。在此示例中，經過foo.bar.com(IP地址爲：178.91.123.132)主機做爲代理服務器。當路徑爲http://foo.bar.cm:80/foo時，將會訪問後端的s1服務；當路徑爲http://foo.bar.cm:80/bar時，將會訪問後端的s2服務。

foo.bar.com -> 178.91.123.132 -> / foo s1:80 / bar s2:80

針對上述場景，Ingress的YAML配置文件以下所示：

apiVersion: extensions/v1beta1 kind: Ingress metadata:  name: mult-ingress  annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec:  rules:  - host: foo.bar.com http:  paths:  - path: /foo backend:  serviceName: s1  servicePort: 80  - path: /bar  backend:  serviceName: s2  servicePort: 80

經過kubctl create -f命令建立上述的Ingress：

$ kubectl get ing 

NAME RULE BACKEND ADDRESS

mult-ingress – foo.bar.com /foo s1:80 /bar s2:80

默認後端：沒有規則的入口，就像前一節中所示的那樣，會將全部的流量發送到一個默認的後端。經過指定一組規則和默認後端，可使用相同的技術來告訴負載均衡器，能夠在哪裏可以找到網站的404頁。若是在Ingress中沒有與請求頭中主機相匹配的主機，而且/或者沒有與請求的URL相匹配的路徑，那麼路由將被路由到默認的後端