分享實錄|NGINX Gateway API(上)
原文作者:林靜
原文鏈接: 分享實錄|NGINX Gateway API(上)
轉載來源:NGINX 開源社區
NGINX 唯一中文官方社區 ,盡在 nginx.org.cn
編者按——本文為 NGINX Sprint China 2022 年度線上大會的分享實錄,點擊文末此處免費觀看大會完整視頻回放。
本文主要講解關於 NGINX Gateway API 的話題,會從五個方面去和大家探討 NGINX Gateway 的技術實現,內容包括什麼是 Gateway API、理解 Gateway API、為何要發展 Gateway API、瞭解 Gateway API 的當前發展、兩個不同的 Gateway API 實現與演示。
大家可能會有一點點疑問,我們經常説的 API Gatewa 和今天講的 Gateway API,只是説法反過來還是完全不同。線上的小夥伴有知道什麼是 Gateway API 的,可以快速在互動區談談對 G·ateway API 的一個印象,或者是關鍵的一些技術點、關鍵要素。
其實 Gateway API 並沒有錯,API Gateway 會在最後一場專門講述,今天這一場講的是用 NGINX 實現 Gateway API。聽起來繞口,深入瞭解之後,大家就會明白為什麼叫 Gateway API。
什麼是 Gateway API?
Gateway API 可以從很多的維度解釋。
首先 Gateway API 是一個項目,屬於 Kubernetes Network Special Interest,也就是 K8s 的興趣小組,這些興趣小組會負責不同的方向, Gateway API 是屬於網絡的 SIG 小組。
在 Kubernetes 的環境下,主要用它去部署 4 層或 7 層的路由以及策略,做很多跟 Kubernetes 網絡層面或者流量通訊層面的事情。就像 PPT 裏面看到的副標題,它其實是一套全新的 Kubernetes 的服務的一種網絡資源。

看到互動羣裏面小夥伴表示剛討論的主語不一樣,從語法上其實就能夠區分出來到底要強調什麼東西。今天要強調的是 API,它是一套資源規範,表現形式是一套 CRD 的資源以及相應的准入控制。
對於開發者或者實現者,這一套本身是接口規範或者是開發規範,因為對於 Gateway API 來説,目前社區只是在定義一個標準,沒有去做具體的實現,所有的實現都要靠第三方去實現,對於開發者來説,這也是一套開發的規範。
正如剛才副標題所講,它是 K8s 中處理流量的一套標準,實際上 Gateway API 本身是從 19 年開始去提這樣的事情。
最早,Gateway API 本身在小組命名是 Service API,我個人認為 Gateway API 會更加貼切一些,更加準確地描述了這套規範所想表達或解決的問題以及對於這套 Kubernetes 與基礎架構之間的關係,所以用 Gateway API 會更準確一些,Service API 感覺上面會更泛一些,或者是它的重點更沒有特別去突出它。
Gateway API 是 Kubernetes 的 KEP,它會有很多的增強 proposal、KEP,Gateway API 應該是 KEP 裏面的 SI 8 或者是 SI 9,是增強規範中建議的。從我們早期的試驗型 Gateway API 的 API 組裏面把它遷移到當前正式的 Gateway API 的資源組裏。
所以相對於 Kubernetes 來説,Gateway API 當前是正式的 Kubernetes 網絡的 API 組資源規範裏面的一個種類,它並不是可有可無的,需要把它當成非常重要的事情去做的規範。

Gateway API 裏面有什麼樣的資源?剛才我們談什麼是 Gateway API,對它做了一些初步定義。首先做一個基本分類、簡單的描述與映射,主要的類型是來自於 Gateway Class、*Routes,這裏面説的包含了 HTTP Route、TLS、TCP、UDP 或者是 GRPC。
未來可能還會有更多 Policy 類型的資源,在使用中這些資源之間是有很多的引用關係。
首先第一點,Gateway Class 你可以理解成是底層基礎,實施層面的某種 proxy 產品或者解決方案的抽象,這個抽象在 Kubernetes 裏面表達為 Gateway Class。從這句話大家就可以理解,Gateway Class 是用來映射到底層的某種解決方案或者是某種提供上的設備或者是一個產品。
所以在這張圖裏面大家可以看到 Gateway Class,它可以表達為公有云上的各種公有云的SLB服務,也可以表達為 NGINX 的 proxy 服務,或者表達為 F5 BIG IP 產品的服務,Gateway Class 就是這樣的一個抽象。
Gateway Class 抽象之後是底層,上層的配置就會由 Gateway 和各種各樣的 Route 去表達。Gateway 是直接和 Gateway Class 進行關聯的一個對象,Gateway 表達的是各種各樣的 proxy 上面的配置的抽象。
比如這樣的一個服務的入口,應該是什麼樣的 IP 地址、什麼樣的端口、什麼樣的協議、什麼樣的證書等等,這些東西都屬於在 Gateway 層面進行表達的,表達完之後它映射到底層具體的解決方案。
上層就是這些解決方案,比如像公有云上的,或者是 NGINX 上的,或者 F5 上各種各樣的配置。Gateway 下面還會引入很多策略性的東西,比如現在有一個 proxy ,有了一個代理,在這個代理之上要加很多的策略,比如七層的策略或者是一些安全的策略等等,這些事情都有各種各樣的 Routes 或者是 policy 進行掛載。
這些 Routes 主要表達的就是 7 層上面各種各樣的處理,接着就會把流量送到 backend 的 service 上面就形成了。可以看出來這些資源對象之間的一些基本的引用關係或者是一些邏輯關係。

Gateway API 有什麼樣的特點,剛才講了定義也講到了基本類型。但是線上有些小夥伴到目前為止還有一些困擾:Gateway API 是不是有點像 Ingress?確實它和 Ingress 有很多地方相通,大家不要混淆。
Gateway API 裏面的特點,有很重要的一點,就是你會發現它可以面向不同的維度去映射不同的東西,那就意味它有角色,就像上一張圖一樣,是底層的基礎設施的提供者。可能是 K8s 平台的管理員,或者是應用的業務管理人員,或者是開發人員,他們都有決策權限。所以在 Gateway API 裏面,它很大的一個特點是面向角色的,不同的角色有不同的資源對象,進行對應映射。
第二個特點是可移植的。剛才我們有提到,社區只是在定義一套規範,但是一套規範並不一定要出一個具體的實現方案,這些方案要由第三方實現,我所定義的這些規範的接口或者是標準,應該在各種環境下都適用,達到同樣的一致性結果,這樣有利於去做各種各樣的遷移,強調一致性。
第三個特點是功能豐富。我們都知道 Kubernetes 裏面 Ingress 能力相對比較弱,很多功能都是依賴於我們去實現 Ingress 這些解決方案廠商所提供的各種各樣的擴展功能,很多的 Annotations 來擴展,但是本身 Ingress 從 Kubernetes 定義 Ingress 資源對象的時候,其實是非常簡單的。
基本的 SSL、HTTP 的路由還是非常簡單的,但是在生產環境中,可能需求不止這些,這個時候標準的 Ingress 可能就不能滿足要求,我們需要有更多的實現。所以 Gateway API 也是基於這一點去解決或者是增強 Ingress 方面所提供的能力不足的問題。
第四點就是可擴展,它與功能豐富其實是在同一個維度上面,但是它又強調了在這些標準之外,還可以擴展出很多東西。這樣就意味着通過擴展的方式可以去兼容或者實現不同的個性化。剛才我們談到實現整個 Gateway API 是由不同廠商去實現,不同廠商會有不同的技術、不同的方案,他們個性化的特點,或者是強項,如何發揮這些強項、如何利用好這些強項,就是在可擴展當中要去做的事情。
第五點就是可跨 NS,它是指可跨 name space 邊界的一個資源引用。這裏面也表達了在 Gateway API 裏面,資源對象是可以跨 name space 引用。比如 Gateway 和 Route 是完全可以在不同的 name space 下的,可以彼此之間引用,引用之間也可以做一些控制。
剛才我們談到,這兩個資源對象是由不同的角色去解決邊界之間的溝通與安全問題,其實也是在 Gateway API 裏面要去解決的。所以跨資源引用以及安全的引用這方面也是 Gateway API 裏面的很重要的部分。
最後一點就是支持不同類型的協議和 backend。不同類型的協議可以理解成上面我們談到的功能豐富裏面的一個維度,但是它還強調了支持不同的 backend。
backend 就是指整個流量從外部進入到 Kubernetes 網關體系,把流量引給了後端標準 Kubernetes 的 service 以及後端的在雲上的某種 serviceless 的 function 函數、存儲桶,比如 S3 這樣的 bucket。這些東西都是由 Gateway API 擴展出來的,也就是在未來通過 Gateway API,不僅僅是向一個服務去引流,而是可以向更多的不同的後端對象去引流,進行控制。所以大家可以看出來,這裏面 Gateway API 的特點就顯現出來了,它不單單是提供某種服務,更多的是表達一種能力。
NGINX 唯一中文官方社區 ,盡在 nginx.org.cn
更多 NGINX 相關的技術乾貨、互動問答、系列課程、活動資源:
- 選擇合適的 API 網關模式,實現有效的 API 交付
- 分享實錄|NGINX Gateway API(下)
- 分享實錄|NGINX Gateway API(上)
- 如何在 NGINX 中安全地分發 SSL 私鑰
- 課程實錄 | 從 0 搭建高可用 Wordpress 博客(上)
- 實現 10 倍應用性能提升的 10 個技巧
- 將 NGINX 部署為 API 網關,第 1 部分
- 避免 10 大 NGINX 配置錯誤(下)
- 如何應對突發的流量激增和服務器過載問題
- 解決 NGINX LDAP 參考實施中的安全問題
- 收藏!0基礎開源數據可視化平台FlyFish大屏開發指南
- 使用 NGINX 作為對象存儲網關
- 藉助 TCP 負載均衡和 Galera 集羣擴展 MySQL
- 一張小圖看盡 Nginx
- 在 Kubernetes 中實施零信任的七條準則
- API 網關 vs. Ingress Controller vs. Service Mesh,該怎麼選?
- NGINX QUIC 和 HTTP/3 開發路線圖
- NGINX Ingress Controller 2.0 版:那些你不得不知道的事兒
- 一把王者的時間,我就學會了 Nginx!
- NGINX 登頂全球 Web 服務器榜單,未來前景更為樂觀