1. 引言
Istio是一個開源的服務網格，主要應用于簡化微服務架構中的服務間通信、提供強大的監控能力以及加強服務的安全管理。通過利用Sidecar模式部署的Envoy代理，Istio能夠在幾乎無需修改服務代碼的情況下，實現服務發現、負載均衡、加密通信、訪問控制等功能。本文將就如何在 Kubernetes 集群環境下，在 istio-system之外的命名空間中配置、部署和應用用戶自定義的網關運行時 Ingress Gateway進行探討。
2. Istio 處理入站請求的流程
在 Kubernetes 集群環境中，默認配置下的 Istio 將會部署至 istio-system 命名空間下，通過向 pod 中自動注入代理容器，Istio 將 pod 納入服務網格的管理之中，實現對服務間通信的統一管理和控制。在 istio-system 命名空間中，網關運行時負責處理所有流入服務網格的外部流量。網關運行時將根據 CRD 資源 Gateway 中的定義監聽特定的域名與端口，并根據 Virtual Service 與 Destination Rule 將請求智能地路由到后端的 Kubernetes Service，并最終訪問到對應的微服務。
3. 為什么需要部署多個網關運行時 Ingress Gateway？
為了保證關鍵應用的可訪問性，用戶可能希望將關鍵應用與一般業務應用進行隔離或單獨配置。此外，在多租戶的情景下，僅利用 Istio-system 命名空間下的默認 Istio 進行管理可能會引起網關運行時宕機，進而導致在訪問各租戶部署的應用時出現異常。
為避免上述可能出現的問題，用戶可以在其他命名空間中，為每個租戶或一組相關服務單獨地部署一套網關運行時Ingress Gateway。這樣做能夠：
1.????? 有效隔離應用間的網絡流量，減少相互影響，提高系統的穩定性和安全性；
2.????? 能夠令用戶根據自身需求定制化網絡策略和配置，如不同的安全策略、路由規則等，而不受全局配置的限制；
3.????? 此外，在默認的 Ingress Gateway出現問題而下線時，應用其它命名空間部署的網關運行時可以減少默認 Ingress Gateway 下線對關鍵應用的影響，便于故障排查和恢復，同時減少對整體服務的影響。
4.?? 用戶自定義網關運行時Ingress Gateway的配置與部署
Ingress Gateway 在 Kubernetes 其他命名空間中的部署依賴于五類 Kubernetes資源，它們默認位于 istio-system 命名空間下，其類型與默認名稱如下所示：
1.????? Deployment: istio-ingressgateway;
2.????? Service: istio-ingressgateway;
3.????? ServiceAccount: istio-ingressgateway-service-account;
4.????? Role: istio-ingressgateway-sds;
5.????? RoleBinding: istio-ingressgateway-sds。
通過獲取 istio-system 命名空間中的 Ingress Gateway 的上述五類資源的 YAML 文件，我們即可獲得一個網關運行時的配置副本模板。之后，通過對上述資源 YAML 文件中的特定字段進行自定義，用戶即可在自己擁有權限的命名空間中部署獨立的 Ingress Gateway 管理應用流量。具體配置修改如下：
對于 Deployment，為了保證 Gateway 資源中的選擇器 Selector 能夠精準匹配到用戶配置的 Ingress Gateway，需要對 Deployment 資源的 Label 進行單獨配置，其中的 app 字段與 istio 字段可由用戶自行定義，如 app: “user-defined”，istio: “user-ingressgateway” 等。之后，再在 Gateway 的 spec.selector 字段中配置上述 label。應保證 Gateway 資源 YAML 中 spec.selector 字段與用戶自建的網關運行時的用戶修改后的 Label 一致，否則會導致 Gateway 資源不能與用戶自建的網關運行時關聯。
為了防止 Istio 將用戶命名空間中部署的 Ingress Gateway 作為普通應用納入服務網格中管理，需要在其 Deployment 的 spec.template.annotations 字段中保證sidecar.istio.io/inject: "false" 字段的存在。
而在 Service 中，可以根據實際需求修改 Service 的類型為 NodePort 或 LoadBalancer。在改為 NodePort 時，需要保證 Service 中配置的五個端口值（status-port，http2，https，tcp，tls）均未被占用。
對于 ServiceAccount、Role與RoleBinding，在修改ServiceAccount與Role的資源名后需要在 RoleBinding 中對應地更新資源名稱。
通過利用修改后的 YAML 在 Kubernetes 集群的特定命名空間中進行部署，即可實現用戶自定義的 Ingress Gateway。在完成 Gateway 的配置之后，后續的 Virtual Service 與 Destination Rule 的配置則與在默認的網關運行時上進行配置的步驟相同。
5.?? 用戶自定義網關運行時Ingress Gateway的應用
在完成上述配置之后，便實現了用戶自建的網關運行時 Ingress Gateway – Gateway – Virtual Service 等資源的聯動，用戶能夠根據 Gateway 的定義利用域名:端口訪問 Kubernetes 集群中的資源。下圖為一個簡單樣例，展示了在按照上述流程設置成功后，訪問集群中某命名空間中的 nginx 的測試頁面。其中，在 Gateway 和 VirtualService 中配置了 a.cn 的路由規則，并在 host 文件中對 a.cn 配置了對應的 IP 地址，端口號為用戶自建的網關運行時的 Service 中的 http2 對應的 Nodeport 端口。
6.?? 總結
本文主要介紹了如何通過獲取位于Kubernetes集群環境中的 istio-ingressgateway 的 yaml 資源模板，以及如何經過用戶自行修改配置并在自己指定的命名空間中部署與應用。
種草環節：歡迎大家下載我們的inBuilder低代碼平臺開源社區版，可免費下載使用，加入我們，開啟開發之旅！
