Kubernetes Ingress實戰(三)：使用Ingress將gRPC服務暴露到Kubernetes叢集外部
為什麼要將RPC/">gRPC服務暴露到Kubernetes叢集外部
在實踐中我們的微服務使用下面的整合方式：
- 所有服務之間使用gRPC通訊, gRPC是我們微服務的最主要的技術棧
- 從整合方式上，將微服務劃分為兩類：
- 基礎服務：這種服務作為聚合服務的後端服務，關注最基礎的模組和功能，基礎服務以gRPC協議暴露
- 聚合服務：聚合多個後端服務成為一個獨立應用的後端服務，聚合服務同時以gRPC和HTTP協議暴露(HTTP暴露使用了grpc-gateway這個代理元件)
在測試和生產環境中，聚合服務往往需要暴露到Kubernetes叢集外部，比如可以是某個前端站點服務(前後端分離)的HTTP API，也可能是某個APP(Android/iOS)的gRPC API。 在開發和測試環境中，基礎服務也需要暴露到Kubernetes叢集外部，因為某個開發人員在開發過程中可能需要呼叫這個由其他團隊負責的基礎服務。
在早期我們使用的NodePort將Kubernetes叢集中gRPC服務暴露到叢集外部，隨著服務數量的增多，在叢集的Node節點上暴露了大量的NodePort埠，同時維護一個很大的埠列表。Nginx從1.13.10開始提供了對gRPC的原生支援，Kubernetes的Nginx Ingress隨後也加入了對gRPC的支援，因此使用Kubernetes的Nginx Ingress可以從7層的暴露gRPC服務到叢集外部。即不需要再為每個gRPC服務暴露一個NodePort，只需為每個gRPC服務分配一個域名就可以將這個gRPC服務從Nginx Ingress Controller的443埠暴露出去。
使用Ingress將gRPC服務暴露到Kubernetes叢集外部
這裡假設Kubernetes叢集中執行一個foo-svc的gRPC Service，以foo-svc為例，將它暴露到叢集外部。 從叢集外部訪問這個服務的域名為 foo-svc.frognew.com ，需要建立 foo-svc.frognew.com 的TLS證書的Secret，這裡是 frognew-tls-secret 。
接下來叢集中為foo-svc建立下面的Ingress資源即可：
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: foo-svc labels: app: foo-svc annotations: nginx.ingress.kubernetes.io/backend-protocol: "GRPC" # nginx.ingress.kubernetes.io/grpc-backend: "true" DEPRECATED since nginx ingress 1.8 nginx.ingress.kubernetes.io/ssl-redirect: "false" spec: rules: - host: foo-svc.frognew.com http: paths: - path: / backend: serviceName: foo-svc servicePort: 80 tls: - hosts: - foo-svc.frognew.com secretName: frognew-tls-secret
注意這裡使用 nginx.ingress.kubernetes.io/backend-protocol: "GRPC" 來致命ingress後端的Service是gRPC協議。 (在nginx ingress controller 1.8之前的版本使用的是 nginx.ingress.kubernetes.io/grpc-backend: "true" )。
關於Nginx Ingress Controller的配置都是通過Annotation實現的，更多配置可參考 NGINX Ingress Annotations 。