編者的話

本文是來自筆者的公司?Tetrate^[1]?工程師 Petr McAllister 的分享，Tetrate 的拳頭產品是?Tetrate Service Bridge^[2]（下文簡稱 TSB），它是在開源的 Istio 和 Envoy 基礎上構建的，但為其增加了管理平面。

簡介

Tetrate 的應用連接平臺 Tetrate Service Bridge（TSB）提供兩種網關類型，分別為一級網關（Tier-1）和二級網關（Tier-2），它們都基于 Envoy 構建，但是目的有所不同。本文將探討這兩種類型網關的功能，以及何時選用哪種網關。

關于兩級網關的簡要介紹：

• ??一級網關（下文簡稱 T1）位于應用邊緣，用于多集群環境。同一應用會同時托管在不同的集群上，T1 網關將對該應用的請求流量在這些集群之間路由。

• ??二級網關（下文簡稱 T2）位于一個的集群邊緣，用于將流量路由到該集群內由服務網格管理的服務。

兩級網關釋義

托管在 TSB 管理的集群中的應用部署的設計與開源的 Istio 模型非常相似。它們的結構相同，使用入口網關來路由傳入的流量。T2 網關相當于 Istio 的入口網關（Ingress Gateway），在邏輯上與 Istio 開源模型相同，如圖 1 所示。

Tetrate Service Bridge 使用 Istio 和 Envoy 構建的服務網格管理集群的控制平面和數據平面，其本身不存在于應用數據路徑中。比較開源 Istio 管理的集群和 TSB 管理的集群之間的數據包路徑，你會發現兩者之間沒有區別。TSB 的配置清單（manifest）被 Istio 消費和使用。通過這種方式，TSB 的作用類似于 CI/CD 自動化邏輯，其中部署過程會影響應用程序的行為，但不會影響應用程序邏輯本身。

TSB 在開源 Istio 的增加了一些組件，以管理每組應用程序網關范圍的安裝和配置，以加快開發和運維人員的工作進度，將基礎設施和應用程序之間的職責分離，將錯誤配置網關的影響與其他應用程序 / 業務組隔離。

何時使用 T1 網關？

當你有兩個或更多的 Kubernetes 集群為同一個應用服務時，為了增加容量、藍綠部署、故障轉移等，問題總是出現：入站流量如何在這些集群之間分配？在每個集群邊緣的 T2 網關允許直接訪問應用程序 —— 例如，集群 A 將監聽?service1A.example.com，集群 X 將監聽?service1X.example.com。反過來，T2 網關提供跨集群的全局負載均衡。跨集群的流量路由分配基于 1 到 100 之間的權重值，指定發送到特定集群的流量的百分比。

下面是一個簡單的 T1 網關配置的例子。這個例子表示了一個完整的 T1 網關清單，以證明該解決方案的簡單性。關于具體設置的細節，請參考?Tetrate API 文檔^?[3]。

apiVersion:?gateway.tsb.tetrate.io/v2
kind:?Tier1Gateway
metadata:name:?service1-tier1group:?demo-gw-grouporganization:?demo-orgtenant:?demo-tenantworkspace:?demo-ws
spec:workloadSelector:namespace:?service1-tier1labels:app:?tsb-gateway-service1-tier1istio:?ingressgatewayexternalServers:-?name:?service1hostname:?service1.cx.example.comport:?80tls:?{}clusters:-?name:?site-1-gcpweight:?75-?name:?site-2-awsweight:?25

在這個例子中，到?service1.cx.example.com?的 75% 用戶請求被轉發到 GCP 中的?site-1，其余的轉發到 AWS 中的?site-2。這個例子中的流量到達明文端口 80，之后 T1 網關和應用集群之間的所有通信都經過 mTLS 加密。

云供應網關整合

Istio 用戶通常按應用模型實施入口網關。這種方法保證了對一個應用程序及其工件的安全、獨立管理。

這里注意到的最常見的痛點 —— 每個應用都需要使用云供應商的負載均衡器。這樣做使得用戶需要維護位于 Envoy 入口網關 Pod 前大量的負載均衡器，這帶來資金開銷和管理成本。

TSB 允許通過 NodePort 服務類型而不是 LoadBalancer 進行服務發現和通信，這意味著不再需要云供應商的負載均衡器；TSB 集群內的服務可以通過 NodePort 直接到達。T1 網關允許我們將云供應商負載均衡器的使用壓縮到一個單一的入口點。

圖 3 展示了通過將集群內的服務連接轉移到 TSB，而不使用云供應商的負載均衡器來簡化云設置。在沒有 TSB 的情況下，要實現上述設置，需要使用外部負載均衡器。TSB 還維護 Kubernetes 節點的列表。

資源要求

就 T2 網關所需的資源而言，開源 Istio 和 TSB 的要求沒有什么不同。事實上，實現方式是一樣的 —— Gateway 和 VirtualService 清單可以手動創建，也可以通過開源的自動化工具創建。在 Tetrate 的用例中，TSB 為 Istio 創建清單。

T1 網關確實需要一個專門的控制平面，這意味著網格管理的應用程序和 T1 網關不能在同一個集群中運行，盡管承載 T1 網關的 Kubernetes 集群也可以承載服務網格以外的應用程序。不過，Tetrate 的有些客戶將 T1 網關放在與 TSB 管理平面相同的集群上。

架構考慮因素

隨著應用環境的發展和成熟，出現新的需求是很常見的。T1 網關可以作為初始服務網格架構實施的一部分進行規劃和實施，也可以在以后添加。增加一級網關只影響入口點的入站流量，但不需要對現有集群做任何改變。

圖 4 展示了一個沒有 T1 網關的部署配置。

當引入 T1 網關時（圖 5），必須更新 DNS 記錄以指向一級網關，而不需要對應用集群的設置進行修改。

注意：TSB 不是 DNS 管理工具，DNS 記錄的更改是在 TSB 之外進行的（有多種自動化工具和技術可用于該操作)。

然而，在添加 T2 網關時，從使用 LoadBalancer 切換到 NodePort 架構，確實需要對應用集群進行輕微的改變。

雖然 T1 網關作為應用邊緣傳入流量的前端，但它可以部署在一個高可用性的配置中（圖 6）。

在高可用性方面，可以使用 T1 網關的數量沒有限制。這種靈活的架構允許用戶建立強大的設計以滿足廣泛的要求。

總結

本文涵蓋了服務網格架構師在企業環境中設計 TSB 部署時最常見的架構問題。以下是最重要的收獲：

• ? TSB T1 和 T2 網關使用 Istio 入口網關 Pod 和服務。這里沒有引入額外的專有組件。

• ? TSB 支持開源 Istio 中的網關模式。僅僅是名稱上的改變，如 TSB 的入口網關被稱為 T2 網關。

• ??單一的網關可以用于所有的應用，也可以采用按應用劃分的網關模式。

• ? TSB 可以通過利用 Kubernetes NodePort 而不是 LoadBalancer 進行集群內通信，減少使用的云廠商負載均衡器的數量，從而降低云計算成本。

• ? TSB T1 網關提供跨集群負載均衡功能。

• ??由于在實施的早期階段可能不需要跨集群負載均衡，因此 T1 網關不需要成為初始部署的一部分，可以在以后添加，對現有的應用程序沒有重大影響。

• ??多個 T1 網關可以部署在同一個應用程序前面，以實現高可用性。

引用鏈接

[1]?Tetrate:?https://tetrate.io/
[2]?Tetrate Service Bridge:?https://tetrate.io/tetrate-service-bridge
[3]?Tetrate API 文檔:?https://docs.tetrate.io/service-bridge/1.4.x/en-us/refs/tsb/gateway/v2/tier1_gateway#tier1gateway

獲取更多云原生社區資訊，加入微信群，請加入云原生社區，點擊閱讀原文了解更多。