作者：如葑

K8s Ingress 簡介

K8s 集群內的網絡與外部是隔離的，即在 K8s 集群外部無法直接訪問集群內部的服務，如何讓將 K8s 集群內部的服務提供給外部用戶呢？K8s 社區有三種方案：NodePort、LoadBalancer、Ingress，下圖是對這三種方案的對比：

通過對比可以看到 Ingress 是更適合業務使用的一種方式，可以基于其做更復雜的二次路由分發，這也是目前用戶主流的選擇。

K8s Ingress 現狀

套用一句流行語：理想是豐滿的、現實是骨感的，這句話放在 K8s Ingress 也同樣適用，K8s 希望通過 Ingress 來標準化集群入口流量的規則定義，但實際業務落地時需要的功能點要遠比 Ingress 提供的多，為了滿足業務訴求，各 Ingress Provider 也各出招數，總的來說解法分成兩類：使用 annotations 擴展與使用新的 CRD。下面使用圖示來說明：

K8s Ingress Provider 的發展趨勢

Ingress Provider 的百花齊放，站在用戶角度各有利弊，好處是用戶的可選項很多，而壞處也恰恰是選擇太多，我們如何去選擇一個適合自身業務的 Ingress Provider 呢？不妨先看看權威 CNCF 的統計數據：

直觀的可以看出對于占據 Ingress Provider 首位的 Nginx 是在預期之內的，細看之下雖 Nginx Ingress 仍占據榜首，但其增長有點乏力，甚至有下降的態勢；反觀 Envoy 已經從 2019 年的第三位攀升至 2020 的第二位，其使用率也從 2019 年的不足 20% 攀升至 2020 年的 37%，幾乎成倍增長。

所謂透過現象看本質，為什么 Envoy 的增長這么快呢？總結起來有以下幾點：

1、Envoy 誕生在分布式微服務的大背景下，其配置熱更新、HTTP3、Wasm 等特性非常貼合目前的使用場景，同時社區治理也非常健康，很多互聯網大廠也深度參與其中。

2、Envoy 即可用作 Ingress Provider，也是 ServiceMesh 中 sidecar 的事實領導者，使用同一種技術同時解決南北向與東西向流量調度也是用戶選擇 Envoy 的一大原因。

3、Envoy 是達到生產級要求的，是經 Lyft 大規模驗證過的。

K8s Ingress Provider 的新選擇 - 云原生網關

在虛擬化時期的微服務架構下，業務通常采用流量網關 + 微服務網關的兩層架構，流量網關負責南北向流量調度和安全防護，微服務網關負責東西向流量調度和服務治理，而在容器和 K8s 主導的云原生時代，Ingress 成為 K8s 生態的網關標準，賦予了網關新的使命，使得流量網關 + 微服務網關合二為一成為可能。

MSE 發布的云原生網關在能力不打折的情況下，將兩層網關變為一層，不僅可以節省 50% 的資源成本，還可以降低運維及使用成本。

云原生網關的優勢

性能更強勁

在開始介紹前先拋個問題：Nginx Ingress 的性能與 Nginx 是等價的嗎？帶著這個疑問我們直接看壓測數據對比：

有沒有感覺很意外呢？說實話壓測后包括我們自己也是有些意外，壓測結論如下：

我們也查看了 Nginx Ingress 的實現以及社區反饋，由于其大量使用 Lua 腳本從而對性能帶來了非常大的影響，K8s Nginx Ingress 社區也有具體的 issue： https://github.com/kubernetes/ingress-nginx/issues/5658

社區壓測 Lua 對 Nginx Ingress 的性能影響截圖如下：

功能更豐富

云原生網關作為流量網關與微服務網關的二合一，其功能上同時提供豐富的安全認證與服務治理能力，同時在性能上也做了內核調優以及接下來要發布的硬件加速功能，結合阿里內部兩年的大促經驗在高可用建設上也進一步做了擴展，整體功能大圖如下：

穩定更可靠

經過歷年大促的驗證，阿里內部積累了一套高可用保障方案，從研發時、運行時、變更時來控制風險提升穩定性，在每個階段各自有手段去驗證其高可用目標，圖示說明如下：

云原生網關即將上線的重磅功能

TLS 硬件加速

目前 HTTPS 已經成為公網請求的主要使用方式，全部使用 HTTPS 后由于其要做 TLS 握手，相比HTTP勢必性能上會有很大損耗，目前隨著 CPU 性能的大幅提升，利用 CPU 的 SIMD 機制可以很好的加速 TLS 的性能，因此我們基于 Intel Ice Lake 處理器推出 TLS 硬件加速功能，通過壓測驗證啟用 TLS 加速后 QPS 可以大幅提升，具體如下圖：

內置 Waf

作為面向南北向的公網網關，使用 Waf 防護異常流量是很常規的需求，而且隨著互聯網環境變得越來越復雜，用戶對防護的訴求是持續增強的，常規做法是將流量先接入 Waf 安全網關，過濾后再將流量轉發給流量網關，最后到達微服務網關；云原生網關希望內置 Waf 模塊直接對接阿里云的 Waf 云產品，使得用戶的請求鏈接只經過云原生網關就可以同時完成 Waf 防護、流量分發、微服務治理，即提升鏈路 RT，也降低網關的運維復雜度，圖示如下：

Wasm 插件市場

Wasm 作為目前非常火熱的技術之一，其最受追捧的原因在于其可以支持多語言編寫 Wasm 程序，且 Wasm 提供了一個很好的沙箱環境來控制程序的執行環境，Istiod 與 Envoy 社區也已經對 Wasm 插件做了基礎的支持，云原生網關希望在社區的基礎上推出自己的插件市場，提升網關的可擴展性，方便用戶自定義網關插件。我們也對現有的 wasm runtime 做了性能對比與測試，這些測試數據也會作為我們的開發依據，圖示如下：

寫在最后

MSE - 云原生網關，旨在為用戶提供更可靠的、成本更低、效率更高的，符合 K8s Ingress 標準的企業級網關產品，更多發布詳情移步直播間觀看： https://yqh.aliyun.com/live/detail/27794

MSE - 云原生網關提供后付費和包年包月兩類付費模式，支持杭州、上海、北京、深圳 、張家口、香港、新加坡、美國（弗吉尼亞）、美國（硅谷）、德國（法蘭克福）10 個 region，并會逐步開放其他 region，云原生網關購買鏈接請點擊此處。

也可釘釘搜索群號 34754806 加入用戶群交流、答疑。 發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布。與你并肩探索云原生技術點滴，分享你需要的云原生內容。

關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！

總結

以上是生活随笔為你收集整理的K8s Ingress Provider 为什么选择 MSE 云原生网关？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。