01

網(wǎng)關(guān)基本概念

在微服務(wù)架構(gòu)里，服務(wù)的粒度被進(jìn)一步細(xì)分，各個(gè)業(yè)務(wù)服務(wù)可以被獨(dú)立的設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、部署和管理。這時(shí)各個(gè)獨(dú)立部署單元可以用不同的開(kāi)發(fā)測(cè)試團(tuán)隊(duì)維護(hù)，可以使用不同的編程語(yǔ)言和技術(shù)平臺(tái)進(jìn)行設(shè)計(jì)，這就要求必須使用一種語(yǔ)言和平臺(tái)無(wú)關(guān)的服務(wù)協(xié)議作為各個(gè)單元間的通訊方式。

網(wǎng)關(guān)的角色是作為一個(gè) API 架構(gòu)，用來(lái)保護(hù)、增強(qiáng)和控制對(duì)于 API 服務(wù)的訪問(wèn)。API 網(wǎng)關(guān)是一個(gè)處于應(yīng)用程序或服務(wù)（提供 REST API 接口服務(wù)）之前的系統(tǒng)，用來(lái)管理授權(quán)、訪問(wèn)控制和流量限制等，這樣 REST API 接口服務(wù)就被 API 網(wǎng)關(guān)保護(hù)起來(lái)，對(duì)所有的調(diào)用者透明。因此隱藏在 API 網(wǎng)關(guān)后面的業(yè)務(wù)系統(tǒng)就可以專(zhuān)注于創(chuàng)建和管理服務(wù)，而不用去處理這些策略性的基礎(chǔ)設(shè)施。

API 網(wǎng)關(guān)是位于客戶(hù)端和后端服務(wù)之間的 API 管理工具，一種將客戶(hù)端接口與后端實(shí)現(xiàn)分離的方式，在微服務(wù)中得到了廣泛的應(yīng)用。當(dāng)客戶(hù)端發(fā)出請(qǐng)求時(shí)，API 網(wǎng)關(guān)會(huì)將其分解為多個(gè)請(qǐng)求，然后將它們路由到正確的位置，生成響應(yīng)，并跟蹤所有內(nèi)容。

API 網(wǎng)關(guān)可看做微服務(wù)架構(gòu)體系中的一類(lèi)型特殊服務(wù)，它是所有微服務(wù)的入口，它的職責(zé)是執(zhí)行路由請(qǐng)求、協(xié)議轉(zhuǎn)換、聚合數(shù)據(jù)、認(rèn)證、限流、熔斷等。大多數(shù)企業(yè) API 都是通過(guò) API 網(wǎng)關(guān)部署的。API 網(wǎng)關(guān)通常會(huì)處理跨 API 服務(wù)系統(tǒng)的常見(jiàn)任務(wù)，例如用戶(hù)身份驗(yàn)證、速率限制和統(tǒng)計(jì)信息。

對(duì)于具體的后端業(yè)務(wù)應(yīng)用或者是服務(wù)和業(yè)務(wù)有一定關(guān)聯(lián)性的策略網(wǎng)關(guān)就是業(yè)務(wù)網(wǎng)關(guān)。 業(yè)務(wù)網(wǎng)關(guān)針對(duì)具體的業(yè)務(wù)需要提供特定的流控策略、緩存策略、鑒權(quán)認(rèn)證策略等等。

與業(yè)務(wù)網(wǎng)關(guān)相反，定義全局性的、跟具體的后端業(yè)務(wù)應(yīng)用和服務(wù)完全無(wú)關(guān)的策略網(wǎng)關(guān)是流量網(wǎng)關(guān)。流量網(wǎng)關(guān)通常只專(zhuān)注于全局的Api管理策略，比如全局流量監(jiān)控、日志記錄、全局限流、黑白名單控制、接入請(qǐng)求到業(yè)務(wù)系統(tǒng)的負(fù)載均衡等，有點(diǎn)類(lèi)似防火墻。

需要說(shuō)明的是，業(yè)務(wù)網(wǎng)關(guān)一般部署在流量網(wǎng)關(guān)之后、業(yè)務(wù)系統(tǒng)之前，比流量網(wǎng)關(guān)更靠近業(yè)務(wù)系統(tǒng)。通常API網(wǎng)指的是業(yè)務(wù)網(wǎng)關(guān)。有時(shí)候也會(huì)模糊流量網(wǎng)關(guān)和業(yè)務(wù)網(wǎng)關(guān)，讓一個(gè)網(wǎng)關(guān)承擔(dān)所有的工作,所以這兩者之間并沒(méi)有嚴(yán)格的界線。

02

云原生網(wǎng)關(guān)作用和規(guī)范

隨著容器化技術(shù)和云原生應(yīng)用的普及，面臨Kubernetes 集群內(nèi)的網(wǎng)絡(luò)環(huán)境與外部隔離， Kubernetes 集群外部的客戶(hù)端無(wú)法直接訪問(wèn)到集群內(nèi)部的服務(wù)的問(wèn)題，需要解決不同網(wǎng)絡(luò)域如何連接的問(wèn)題。解決跨網(wǎng)絡(luò)域訪問(wèn)的常規(guī)做法是為目標(biāo)集群引入一個(gè)入口點(diǎn)，所有外部請(qǐng)求目標(biāo)集群的流量必須訪問(wèn)這個(gè)入口點(diǎn)，然后由入口點(diǎn)將外部請(qǐng)求轉(zhuǎn)發(fā)至目標(biāo)節(jié)點(diǎn)。

同樣，Kubernetes 社區(qū)也是通過(guò)增設(shè)入口點(diǎn)的方案來(lái)解決集群內(nèi)部服務(wù)如何對(duì)外暴露的問(wèn)題。Kubernetes 一貫的作風(fēng)是通過(guò)定義標(biāo)準(zhǔn)來(lái)解決同一類(lèi)問(wèn)題，在解決集群對(duì)外流量管理的問(wèn)題也不例外。Kubernetes 對(duì)集群入口點(diǎn)進(jìn)行了進(jìn)一步的統(tǒng)一抽象，提出了 3 種解決方案：NodePort、LoadBalancer 和 Ingress。下圖是這三種方案的對(duì)比：

通過(guò)對(duì)比可以發(fā)現(xiàn)，NodePort 和 LoadBalancer 主要工作在四層流量上，只能用于暴露集群中一個(gè)服務(wù)。當(dāng)集群中對(duì)外暴露的服務(wù)數(shù)量增多時(shí)，NodePort 方案最終會(huì)因端口耗盡而無(wú)法暴露更多的服務(wù)，而 LoadBalancer 方案則會(huì)引入同等數(shù)量的 SLB，在增加成本的同時(shí)也給運(yùn)維增加負(fù)擔(dān)。定位在七層流量上的 Ingress 方案可以通過(guò)定義基于虛擬主機(jī)域和路徑的路由規(guī)則來(lái)完成對(duì)集群中服務(wù)的代理，Ingress 與后端服務(wù)是一對(duì)多的關(guān)系，有效的降低了機(jī)器成本。

此外，因?yàn)橥獠吭L問(wèn)集群中服務(wù)的所有入口流量都先經(jīng)過(guò)共享的 Ingress Provider 節(jié)點(diǎn)，所以集群管理者可以在 Ingress Provider 中額外實(shí)施訪問(wèn)控制策略來(lái)保證集群中服務(wù)的安全性和穩(wěn)定性，并且可以通過(guò)采集監(jiān)控指標(biāo)、記錄訪問(wèn)日志以及開(kāi)啟鏈路追蹤來(lái)增強(qiáng)可觀測(cè)建設(shè)。因此目前 Ingress 方案是主流的選擇。

03

Ingress規(guī)范

簡(jiǎn)單講，Ingress是 Kubernetes 處理邊緣入口流量的一種方式。由于 Kubernetes 集群內(nèi)的服務(wù)都是虛擬網(wǎng)絡(luò)，外部流量訪問(wèn)集群內(nèi)部至少需要一個(gè)公網(wǎng)ip和端口映射。Ingress 是 Kubernetes 應(yīng)對(duì)集群管理外部訪問(wèn)流量的場(chǎng)景抽象出來(lái)一個(gè)資源對(duì)象，用來(lái)描述集群外部如何訪問(wèn)集群內(nèi)部服務(wù)的方式。

上文所述Kubernetes 有多種暴露邊緣接口的方式，相比而言ingress 通過(guò)暴露有限的公網(wǎng) ip，使用反向代理的方式，無(wú)疑是一種更加有競(jìng)爭(zhēng)力的方式。說(shuō)到反向代理，我們也可以直接搭建一個(gè) Nginx 來(lái)做反向代理，但是要在 Nginx 里同步 Kubernetes 中隨時(shí)可變的服務(wù)狀態(tài)，明顯增加了維護(hù)難度。好在 Kubernetes 官方提供并維護(hù)了一個(gè) nginx ingress controller，幫助我們解決了反向代理的事情，有了這個(gè) nginx ingress controller，可以幫助我們代理所有想要訪問(wèn) Kubernetes 的外部流量，并且將流量正確的指向后端服務(wù)。通過(guò) Ingress 資源來(lái)配置不同的轉(zhuǎn)發(fā)規(guī)則，從而達(dá)到根據(jù)不同的規(guī)則設(shè)置外部訪問(wèn)集群內(nèi)不同的 Service 所對(duì)應(yīng)的后端 Pod。

Ingress Controller是真實(shí)存在的工作負(fù)載節(jié)點(diǎn)，是真正意義上 Ingress 規(guī)則的實(shí)現(xiàn)者與執(zhí)行者。Kubernetes 提出 Ingress 的規(guī)范，將 Ingress 具體實(shí)現(xiàn)方式交給各種 Provider 以及云提供商，有效保證了 Ingress 不會(huì)被具體的 Provider 或者云廠商綁定，符合 Kubernetes 一直秉承的開(kāi)放、標(biāo)準(zhǔn)的思想。

在云原生技術(shù)浪潮下，Ingress Provider 產(chǎn)品種類(lèi)如雨后春筍般涌現(xiàn)，其中用戶(hù)知名度最高當(dāng)屬 Kubernetes Nginx Ingress。Nginx Ingress Controller 是由 Kubernetes 官方維護(hù)的，內(nèi)部由 Controller 和數(shù)據(jù)面 Nginx 組成。Nginx Ingress Controller 由用戶(hù)部署在 Kubernetes 集群中，通過(guò)訪問(wèn)集群的 API Server 來(lái)實(shí)時(shí)監(jiān)聽(tīng)用戶(hù)應(yīng)用到集群中的 Ingress 資源，經(jīng) Controller 解析并轉(zhuǎn)化為 Nginx 配置文件（nginx.conf)，然后通過(guò) reload 數(shù)據(jù)面 Nginx 的方式使得配置生效。當(dāng)外部請(qǐng)求訪問(wèn)集群入口點(diǎn) Nginx Ingress Controller 時(shí)，匹配 Nginx Ingress 轉(zhuǎn)發(fā)規(guī)則的流量轉(zhuǎn)發(fā)到后端 Service 所對(duì)應(yīng)的 Pod，由 Pod 處理外部請(qǐng)求。

下圖是一個(gè)典型的Ingress配置示例，可以基于同一域名提供細(xì)分的服務(wù)。

通過(guò)基于名稱(chēng)的虛擬主機(jī)支持，可以將針對(duì)多個(gè)服務(wù)的 HTTP 流量路由到同一 IP 地址上。

04

Gateway API規(guī)范

在 Kubernetes 集群邊緣對(duì)外提供網(wǎng)絡(luò)服務(wù)的時(shí)候，通常需要借助 Ingress 對(duì)象，這個(gè)對(duì)象提供了暴露 Service 所必須的核心要素，例如基于主機(jī)名的路由、對(duì) URL 路徑的適配以及 TLS 配置等。但是在實(shí)際開(kāi)放服務(wù)的時(shí)候，往往會(huì)有更多的具體需求，這時(shí) Ingress 對(duì)象所提供的核心功能就有些力不從心了。

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

K8s 官方SIG-Network工作組基于實(shí)際現(xiàn)狀和需求，提出了全新的 Gateway API 來(lái)作為 Ingress 的繼任者?？傮w來(lái)說(shuō)，相對(duì)于 Ingress，Gateway API 有幾個(gè)顯著特點(diǎn)：職責(zé)分離，運(yùn)維、開(kāi)發(fā)等不同的角色都能夠在適合的邊界內(nèi)完成工作；擴(kuò)展核心能力，并使用更結(jié)構(gòu)化的方式進(jìn)行表達(dá)；易于擴(kuò)展，Gateway API 為各種不同實(shí)現(xiàn)的控制器提供了一致的擴(kuò)展方法。

Gateway API 包含了三層概念：GatewayClass、Gateway 和 Route，其中的 Route 實(shí)際是包含了 HTTPRoute、TCPRoute、TLSRoute 和 UDPRoute 在內(nèi)的一組對(duì)象。

GatewayClass是一個(gè)集群范圍內(nèi)的資源，由云基礎(chǔ)設(shè)施中的 Gateway API 控制器提供，其職責(zé)和原有的 Ingress Controller 類(lèi)似。

Gateway 對(duì)象是命名空間范圍對(duì)象，可以視作是 GatewayClass 的一個(gè)實(shí)例，它通常是由具體機(jī)群的運(yùn)維人員進(jìn)行維護(hù)的，在 Gateway 對(duì)象中可以指定該對(duì)象負(fù)責(zé)的主機(jī)名稱(chēng)范圍，用標(biāo)簽選擇器選擇對(duì)應(yīng)的 Service，甚至還可以指定該 Gateway 生效的命名空間。這樣就給具體應(yīng)用的對(duì)外開(kāi)放劃定了一個(gè)范圍，防止應(yīng)用隨意占用主機(jī)名，并完善命名空間的隔離能力。

Route 對(duì)象除了像原有的 Ingress 對(duì)象一樣提供 HTTP 服務(wù)的開(kāi)放能力之外，還提供了 TCP、TLS 和 UDP 的對(duì)應(yīng)資源，從而緩解了 Nginx、HAProxy Ingress 控制器使用 Configmap 配置 TCP/UDP 的窘境。HTTPRoute 除了提供基礎(chǔ)的 Ingress 對(duì)象能力之外，還提供了一些擴(kuò)展的功能，例如對(duì)流量進(jìn)行復(fù)制、分流；更重要的是其中還提供了 Filter 能力，這是一個(gè)擴(kuò)展點(diǎn)，除了自帶的核心處理能力之外，底層設(shè)施還可以在這里接入自己的 CRD，對(duì)流量進(jìn)行處理，從而為流量處理能力的擴(kuò)展提供了一個(gè)統(tǒng)一入口。

值得注意的是，當(dāng)前Gateway API規(guī)范還在快速發(fā)展和完善中。

05

云原生網(wǎng)關(guān)選型

標(biāo)準(zhǔn)Nginx ingress controller 幫助維護(hù)了 Kubernetes 集群與 Nginx 的狀態(tài)同步，并且提供了基本的反向代理能力，為什么還要自己造輪子呢? 隨著云原生技術(shù)持續(xù)演進(jìn)，云原生應(yīng)用微服務(wù)化不斷深入，Nginx Ingress 在面對(duì)復(fù)雜路由規(guī)則配置、支持多種應(yīng)用層協(xié)議（Dubbo 和 QUIC 等）、服務(wù)訪問(wèn)的安全性以及流量的可觀測(cè)性等問(wèn)題上略顯疲憊。

在使用 Kubernetes 原生 ingress controller 之后，以下幾點(diǎn)比較突出的問(wèn)題:

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

2、在 annotation 中寫(xiě)腳本、填充參數(shù)：原生 ingress controller 支持在 yaml 中 annotation 定義腳本片段，感覺(jué)是為了支持高級(jí)功能而實(shí)現(xiàn)的一個(gè)臨時(shí)方案，不好管理。大量的 annotation 腳本給配置人員帶來(lái)困擾。

3、缺少對(duì)有狀態(tài)負(fù)載均衡的支持：高級(jí)的負(fù)載均衡策略并沒(méi)有支持，比如 session persistent 等。

4、動(dòng)態(tài)調(diào)整權(quán)重：業(yè)務(wù)服務(wù)常常需要按照百分比控制流量，這在 Kubernetes 中卻變成了麻煩。雖然 Kubernetes 在1.8之后支持了 ipvs，無(wú)論是 kube-proxy 的啟動(dòng)參數(shù)，還是 kube-route 的 annotation，在使用上都不容易上手。

5、擴(kuò)展能力薄弱：雖然 ingress 設(shè)計(jì)之初為了解決邊緣流量，但人們對(duì)于邊緣流量的需求一點(diǎn)都不比內(nèi)部流量少。業(yè)務(wù)級(jí)灰度控制、熔斷、流量控制、鑒權(quán)、流量管控等需求在 ingress 上實(shí)現(xiàn)的呼聲更高。然而原生 ingress 提供的擴(kuò)展此時(shí)卻捉襟?肘。

業(yè)務(wù)的需求不容忽視，我們對(duì) ingress controller 有更多的期待。好在業(yè)界有多款云原生網(wǎng)關(guān)供選擇，

云原生網(wǎng)關(guān)選型需要綜合考慮以下方面：是否開(kāi)源，以及開(kāi)源版本的功能和商業(yè)版區(qū)別，以及是否有特定公司主導(dǎo)還是社區(qū)整體主導(dǎo)。支持的服務(wù)發(fā)現(xiàn)規(guī)范也是重要的考慮因素。底層代理的實(shí)現(xiàn)方式是重要考慮因素，當(dāng)前主要有Nginx內(nèi)核，Envoy內(nèi)核和Go語(yǔ)言自主開(kāi)發(fā)實(shí)現(xiàn)幾種方式，內(nèi)核實(shí)現(xiàn)方式直接影響網(wǎng)關(guān)性能和可擴(kuò)展性。另外，流量治理的功能豐富性和命名空間隔離能力也是考慮的重要因素。

下圖是幾種當(dāng)前主流網(wǎng)關(guān)的各項(xiàng)指標(biāo)對(duì)比。

需要說(shuō)明的是Istio內(nèi)置的Istio網(wǎng)關(guān)，對(duì)于策略控制、流量管理和流量監(jiān)控可以直接通過(guò) Istio 網(wǎng)關(guān)來(lái)完成，這樣做的好處是通過(guò) Istio 的控制平面來(lái)直接管理網(wǎng)關(guān)，而不需要再借助其他工具。

但是對(duì)于 API 生命周期管理、復(fù)雜的計(jì)費(fèi)、協(xié)議轉(zhuǎn)換和認(rèn)證等功能，成熟的 API 網(wǎng)關(guān)如Kong和Apisix可能更適合。Apache APISIX 支持熱配置，隨時(shí)可以定義和修改路由，而且不會(huì)觸發(fā) nginx reload。在Apache APISIX中，可以通過(guò)插件代碼編寫(xiě)邏輯，暴露出簡(jiǎn)單的配置接口，方便配置的維護(hù)，避免腳本對(duì)配置人員的干擾。

基于 Apache APISIX 可以擴(kuò)展出符合要求的高級(jí)負(fù)載均衡需求，Apache APISIX 不僅原生支持了 session persistent 等負(fù)載均衡，同時(shí)還預(yù)留 balancer 階段的擴(kuò)展能力。Apache APISIX 內(nèi)部抽象出 route、service、consumer、upstream、plugin 等主要對(duì)象，對(duì)調(diào)整路由權(quán)重這類(lèi)操作天然支持，只需簡(jiǎn)單的修改upstream 下的 node weight 即可。APISIX 在擴(kuò)展能力上提供了插件的支持，除了官方提供的插件之外，可以自定義開(kāi)發(fā)滿(mǎn)足自身業(yè)務(wù)特性的插件。

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

新的Envoy Gateway 項(xiàng)目的誕生為了進(jìn)一步統(tǒng)一基于Envoy的云原生網(wǎng)關(guān)：提供一個(gè)簡(jiǎn)化的部署模型和API 層，旨在滿(mǎn)足輕量級(jí)使用。將現(xiàn)有的 CNCF API 網(wǎng)關(guān)項(xiàng)目（Contour 和 Emissary）合并為一個(gè)共同的核，基于Gateway API規(guī)范可以提供更好的用戶(hù)體驗(yàn)，同時(shí)仍然允許供應(yīng)商在 Envoy Proxy 和 Envoy Gateway 的基礎(chǔ)上建立增值解決方案。

匯聚在單一的以 Envoy 為核心的 API 網(wǎng)關(guān)周?chē)瑢?huì)減少?lài)@安全、控制平面技術(shù)細(xì)節(jié)和其他共同關(guān)切的重復(fù)工作。允許供應(yīng)商專(zhuān)注于在 Envoy Proxy 和 Envoy Gateway 的基礎(chǔ)上以擴(kuò)展、管理平面 UI 等形式分層提供增值功能。

讓更多的用戶(hù)享受到 Envoy 的好處，無(wú)論組織的大小。更多的用戶(hù)為更多的潛在客戶(hù)提供了良性循環(huán)，為 Envoy 的核心項(xiàng)目提供了更多的支持，也為所有人提供了更好的整體體驗(yàn)。

整體看，當(dāng)前基于Nginx內(nèi)核的網(wǎng)關(guān)如Kong和Apisix由于功能豐富度和成熟度水平較高，可以較好的滿(mǎn)足云原生網(wǎng)關(guān)的功能需求。長(zhǎng)期看，基于Envoy的網(wǎng)關(guān)由于技術(shù)的新穎性，在動(dòng)態(tài)配置管理，可擴(kuò)展性，以及安全和可觀測(cè)性方面的先進(jìn)性，是未來(lái)的技術(shù)趨勢(shì)。

工程師是 API 和 API 網(wǎng)關(guān)的使用者和開(kāi)發(fā)者，工程師關(guān)注和參與的 API 網(wǎng)關(guān)項(xiàng)目，一定程度代表了技術(shù)的趨勢(shì)。下圖從 GitHub 代碼貢獻(xiàn)者的維度，選取了 4 個(gè)開(kāi)源網(wǎng)關(guān)產(chǎn)品進(jìn)行對(duì)比：Apache APISIX、Kong、EnvoyGateway和 Istio，可做參考。

除了貢獻(xiàn)者總數(shù)外，貢獻(xiàn)者的月度活躍數(shù)也是重要參考指標(biāo)。下圖展示了以上四個(gè)開(kāi)源 網(wǎng)關(guān)的月度活躍的開(kāi)發(fā)者數(shù)量。可以看到各網(wǎng)關(guān)產(chǎn)品的開(kāi)發(fā)活躍趨勢(shì)。

參考文獻(xiàn)

1.從概念到實(shí)踐上手 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