01

網關基本概念

在微服務架構里，服務的粒度被進一步細分，各個業務服務可以被獨立的設計、開發、測試、部署和管理。這時各個獨立部署單元可以用不同的開發測試團隊維護，可以使用不同的編程語言和技術平臺進行設計，這就要求必須使用一種語言和平臺無關的服務協議作為各個單元間的通訊方式。

網關的角色是作為一個 API 架構，用來保護、增強和控制對于 API 服務的訪問。API 網關是一個處于應用程序或服務（提供 REST API 接口服務）之前的系統，用來管理授權、訪問控制和流量限制等，這樣 REST API 接口服務就被 API 網關保護起來，對所有的調用者透明。因此隱藏在 API 網關后面的業務系統就可以專注于創建和管理服務，而不用去處理這些策略性的基礎設施。

API 網關是位于客戶端和后端服務之間的 API 管理工具，一種將客戶端接口與后端實現分離的方式，在微服務中得到了廣泛的應用。當客戶端發出請求時，API 網關會將其分解為多個請求，然后將它們路由到正確的位置，生成響應，并跟蹤所有內容。

API 網關可看做微服務架構體系中的一類型特殊服務，它是所有微服務的入口，它的職責是執行路由請求、協議轉換、聚合數據、認證、限流、熔斷等。大多數企業 API 都是通過 API 網關部署的。API 網關通常會處理跨 API 服務系統的常見任務，例如用戶身份驗證、速率限制和統計信息。

對于具體的后端業務應用或者是服務和業務有一定關聯性的策略網關就是業務網關。 業務網關針對具體的業務需要提供特定的流控策略、緩存策略、鑒權認證策略等等。

與業務網關相反，定義全局性的、跟具體的后端業務應用和服務完全無關的策略網關是流量網關。流量網關通常只專注于全局的Api管理策略，比如全局流量監控、日志記錄、全局限流、黑白名單控制、接入請求到業務系統的負載均衡等，有點類似防火墻。

需要說明的是，業務網關一般部署在流量網關之后、業務系統之前，比流量網關更靠近業務系統。通常API網指的是業務網關。有時候也會模糊流量網關和業務網關，讓一個網關承擔所有的工作,所以這兩者之間并沒有嚴格的界線。

02

云原生網關作用和規范

隨著容器化技術和云原生應用的普及，面臨Kubernetes 集群內的網絡環境與外部隔離， Kubernetes 集群外部的客戶端無法直接訪問到集群內部的服務的問題，需要解決不同網絡域如何連接的問題。解決跨網絡域訪問的常規做法是為目標集群引入一個入口點，所有外部請求目標集群的流量必須訪問這個入口點，然后由入口點將外部請求轉發至目標節點。

同樣，Kubernetes 社區也是通過增設入口點的方案來解決集群內部服務如何對外暴露的問題。Kubernetes 一貫的作風是通過定義標準來解決同一類問題，在解決集群對外流量管理的問題也不例外。Kubernetes 對集群入口點進行了進一步的統一抽象，提出了 3 種解決方案：NodePort、LoadBalancer 和 Ingress。下圖是這三種方案的對比：

通過對比可以發現，NodePort 和 LoadBalancer 主要工作在四層流量上，只能用于暴露集群中一個服務。當集群中對外暴露的服務數量增多時，NodePort 方案最終會因端口耗盡而無法暴露更多的服務，而 LoadBalancer 方案則會引入同等數量的 SLB，在增加成本的同時也給運維增加負擔。定位在七層流量上的 Ingress 方案可以通過定義基于虛擬主機域和路徑的路由規則來完成對集群中服務的代理，Ingress 與后端服務是一對多的關系，有效的降低了機器成本。

此外，因為外部訪問集群中服務的所有入口流量都先經過共享的 Ingress Provider 節點，所以集群管理者可以在 Ingress Provider 中額外實施訪問控制策略來保證集群中服務的安全性和穩定性，并且可以通過采集監控指標、記錄訪問日志以及開啟鏈路追蹤來增強可觀測建設。因此目前 Ingress 方案是主流的選擇。

03

Ingress規范

簡單講，Ingress是 Kubernetes 處理邊緣入口流量的一種方式。由于 Kubernetes 集群內的服務都是虛擬網絡，外部流量訪問集群內部至少需要一個公網ip和端口映射。Ingress 是 Kubernetes 應對集群管理外部訪問流量的場景抽象出來一個資源對象，用來描述集群外部如何訪問集群內部服務的方式。

上文所述Kubernetes 有多種暴露邊緣接口的方式，相比而言ingress 通過暴露有限的公網 ip，使用反向代理的方式，無疑是一種更加有競爭力的方式。說到反向代理，我們也可以直接搭建一個 Nginx 來做反向代理，但是要在 Nginx 里同步 Kubernetes 中隨時可變的服務狀態，明顯增加了維護難度。好在 Kubernetes 官方提供并維護了一個 nginx ingress controller，幫助我們解決了反向代理的事情，有了這個 nginx ingress controller，可以幫助我們代理所有想要訪問 Kubernetes 的外部流量，并且將流量正確的指向后端服務。通過 Ingress 資源來配置不同的轉發規則，從而達到根據不同的規則設置外部訪問集群內不同的 Service 所對應的后端 Pod。

Ingress Controller是真實存在的工作負載節點，是真正意義上 Ingress 規則的實現者與執行者。Kubernetes 提出 Ingress 的規范，將 Ingress 具體實現方式交給各種 Provider 以及云提供商，有效保證了 Ingress 不會被具體的 Provider 或者云廠商綁定，符合 Kubernetes 一直秉承的開放、標準的思想。

在云原生技術浪潮下，Ingress Provider 產品種類如雨后春筍般涌現，其中用戶知名度最高當屬 Kubernetes Nginx Ingress。Nginx Ingress Controller 是由 Kubernetes 官方維護的，內部由 Controller 和數據面 Nginx 組成。Nginx Ingress Controller 由用戶部署在 Kubernetes 集群中，通過訪問集群的 API Server 來實時監聽用戶應用到集群中的 Ingress 資源，經 Controller 解析并轉化為 Nginx 配置文件（nginx.conf)，然后通過 reload 數據面 Nginx 的方式使得配置生效。當外部請求訪問集群入口點 Nginx Ingress Controller 時，匹配 Nginx Ingress 轉發規則的流量轉發到后端 Service 所對應的 Pod，由 Pod 處理外部請求。

下圖是一個典型的Ingress配置示例，可以基于同一域名提供細分的服務。

通過基于名稱的虛擬主機支持，可以將針對多個服務的 HTTP 流量路由到同一 IP 地址上。

04

Gateway API規范

在 Kubernetes 集群邊緣對外提供網絡服務的時候，通常需要借助 Ingress 對象，這個對象提供了暴露 Service 所必須的核心要素，例如基于主機名的路由、對 URL 路徑的適配以及 TLS 配置等。但是在實際開放服務的時候，往往會有更多的具體需求，這時 Ingress 對象所提供的核心功能就有些力不從心了。

各種 Ingress 控制器往往會使用 metadata.annotations 中的特定注解，來完成對 Ingress 特定行為的控制，完成各自的個性化功能，例如認證、路徑變更、黑白名單等，這就讓 Ingress 對象變成了一個奇怪的東西：結構化的核心結構，和非結構化的標注結合起來形成各種 Ingress 方言。并且后期還出現了 各種CRD 配置，客觀上也讓 Ingress 世界更為分裂，這給 Ingress 功能的集中管理造成了一個較大的困擾。另外 Ingress 中可以隨意定制主機名、路徑以及后端服務，也給共享集群的用戶造成了一定的安全隱患。

K8s 官方SIG-Network工作組基于實際現狀和需求，提出了全新的 Gateway API 來作為 Ingress 的繼任者。總體來說，相對于 Ingress，Gateway API 有幾個顯著特點：職責分離，運維、開發等不同的角色都能夠在適合的邊界內完成工作；擴展核心能力，并使用更結構化的方式進行表達；易于擴展，Gateway API 為各種不同實現的控制器提供了一致的擴展方法。

Gateway API 包含了三層概念：GatewayClass、Gateway 和 Route，其中的 Route 實際是包含了 HTTPRoute、TCPRoute、TLSRoute 和 UDPRoute 在內的一組對象。

GatewayClass是一個集群范圍內的資源，由云基礎設施中的 Gateway API 控制器提供，其職責和原有的 Ingress Controller 類似。

Gateway 對象是命名空間范圍對象，可以視作是 GatewayClass 的一個實例，它通常是由具體機群的運維人員進行維護的，在 Gateway 對象中可以指定該對象負責的主機名稱范圍，用標簽選擇器選擇對應的 Service，甚至還可以指定該 Gateway 生效的命名空間。這樣就給具體應用的對外開放劃定了一個范圍，防止應用隨意占用主機名，并完善命名空間的隔離能力。

Route 對象除了像原有的 Ingress 對象一樣提供 HTTP 服務的開放能力之外，還提供了 TCP、TLS 和 UDP 的對應資源，從而緩解了 Nginx、HAProxy Ingress 控制器使用 Configmap 配置 TCP/UDP 的窘境。HTTPRoute 除了提供基礎的 Ingress 對象能力之外，還提供了一些擴展的功能，例如對流量進行復制、分流；更重要的是其中還提供了 Filter 能力，這是一個擴展點，除了自帶的核心處理能力之外，底層設施還可以在這里接入自己的 CRD，對流量進行處理，從而為流量處理能力的擴展提供了一個統一入口。

值得注意的是，當前Gateway API規范還在快速發展和完善中。

05

云原生網關選型

標準Nginx ingress controller 幫助維護了 Kubernetes 集群與 Nginx 的狀態同步，并且提供了基本的反向代理能力，為什么還要自己造輪子呢? 隨著云原生技術持續演進，云原生應用微服務化不斷深入，Nginx Ingress 在面對復雜路由規則配置、支持多種應用層協議（Dubbo 和 QUIC 等）、服務訪問的安全性以及流量的可觀測性等問題上略顯疲憊。

在使用 Kubernetes 原生 ingress controller 之后，以下幾點比較突出的問題:

1、reload 問題：Kubernetes 原生 ingress 在設計上，將 YAML 配置文件交由 ingress controller 處理，轉換為 nginx.conf，再觸發 reload nginx.conf 使配置生效。日常運維免不了修改 ingress 配置，每一次配置生效，都會觸發一次 reload，這是不能接受的，尤其在邊緣流量采用?連接時，更容易導致事故。

2、在 annotation 中寫腳本、填充參數：原生 ingress controller 支持在 yaml 中 annotation 定義腳本片段，感覺是為了支持高級功能而實現的一個臨時方案，不好管理。大量的 annotation 腳本給配置人員帶來困擾。

3、缺少對有狀態負載均衡的支持：高級的負載均衡策略并沒有支持，比如 session persistent 等。

4、動態調整權重：業務服務常常需要按照百分比控制流量，這在 Kubernetes 中卻變成了麻煩。雖然 Kubernetes 在1.8之后支持了 ipvs，無論是 kube-proxy 的啟動參數，還是 kube-route 的 annotation，在使用上都不容易上手。

5、擴展能力薄弱：雖然 ingress 設計之初為了解決邊緣流量，但人們對于邊緣流量的需求一點都不比內部流量少。業務級灰度控制、熔斷、流量控制、鑒權、流量管控等需求在 ingress 上實現的呼聲更高。然而原生 ingress 提供的擴展此時卻捉襟?肘。

業務的需求不容忽視，我們對 ingress controller 有更多的期待。好在業界有多款云原生網關供選擇，

云原生網關選型需要綜合考慮以下方面：是否開源，以及開源版本的功能和商業版區別，以及是否有特定公司主導還是社區整體主導。支持的服務發現規范也是重要的考慮因素。底層代理的實現方式是重要考慮因素，當前主要有Nginx內核，Envoy內核和Go語言自主開發實現幾種方式，內核實現方式直接影響網關性能和可擴展性。另外，流量治理的功能豐富性和命名空間隔離能力也是考慮的重要因素。

下圖是幾種當前主流網關的各項指標對比。

需要說明的是Istio內置的Istio網關，對于策略控制、流量管理和流量監控可以直接通過 Istio 網關來完成，這樣做的好處是通過 Istio 的控制平面來直接管理網關，而不需要再借助其他工具。

但是對于 API 生命周期管理、復雜的計費、協議轉換和認證等功能，成熟的 API 網關如Kong和Apisix可能更適合。Apache APISIX 支持熱配置，隨時可以定義和修改路由，而且不會觸發 nginx reload。在Apache APISIX中，可以通過插件代碼編寫邏輯，暴露出簡單的配置接口，方便配置的維護，避免腳本對配置人員的干擾。

基于 Apache APISIX 可以擴展出符合要求的高級負載均衡需求，Apache APISIX 不僅原生支持了 session persistent 等負載均衡，同時還預留 balancer 階段的擴展能力。Apache APISIX 內部抽象出 route、service、consumer、upstream、plugin 等主要對象，對調整路由權重這類操作天然支持，只需簡單的修改upstream 下的 node weight 即可。APISIX 在擴展能力上提供了插件的支持，除了官方提供的插件之外，可以自定義開發滿足自身業務特性的插件。

由于Envoy的復雜性，雖然該項目在世界各地的大型工程組織中取得了巨大的成功，但在較小和較簡單的用例中，它只被輕度采用，在這些用例中，Nginx 和 HAProxy 仍占主導地位。

新的Envoy Gateway 項目的誕生為了進一步統一基于Envoy的云原生網關：提供一個簡化的部署模型和API 層，旨在滿足輕量級使用。將現有的 CNCF API 網關項目（Contour 和 Emissary）合并為一個共同的核，基于Gateway API規范可以提供更好的用戶體驗，同時仍然允許供應商在 Envoy Proxy 和 Envoy Gateway 的基礎上建立增值解決方案。

匯聚在單一的以 Envoy 為核心的 API 網關周圍，將會減少圍繞安全、控制平面技術細節和其他共同關切的重復工作。允許供應商專注于在 Envoy Proxy 和 Envoy Gateway 的基礎上以擴展、管理平面 UI 等形式分層提供增值功能。

讓更多的用戶享受到 Envoy 的好處，無論組織的大小。更多的用戶為更多的潛在客戶提供了良性循環，為 Envoy 的核心項目提供了更多的支持，也為所有人提供了更好的整體體驗。

整體看，當前基于Nginx內核的網關如Kong和Apisix由于功能豐富度和成熟度水平較高，可以較好的滿足云原生網關的功能需求。長期看，基于Envoy的網關由于技術的新穎性，在動態配置管理，可擴展性，以及安全和可觀測性方面的先進性，是未來的技術趨勢。

工程師是 API 和 API 網關的使用者和開發者，工程師關注和參與的 API 網關項目，一定程度代表了技術的趨勢。下圖從 GitHub 代碼貢獻者的維度，選取了 4 個開源網關產品進行對比：Apache APISIX、Kong、EnvoyGateway和 Istio，可做參考。

除了貢獻者總數外，貢獻者的月度活躍數也是重要參考指標。下圖展示了以上四個開源 網關的月度活躍的開發者數量。可以看到各網關產品的開發活躍趨勢。

參考文獻

1.從概念到實踐上手 Apache APISIX Ingress

2.Apache APISIX

3.Introduction - Kubernetes Gateway API

4.Ingress | Kubernetes

5.GitHub Contributor Over Time (git-contributor.com)

6.envoyproxy/gateway