作者：如葑

## K8s Ingress 簡介

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/09aa84e33c8741fb9f4bc4dc702ae6dd.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

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

## K8s Ingress 現狀

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/92b0fc6f06fc4a8dbbf2977abc701847.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## K8s Ingress Provider 的發展趨勢

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/2277a689cc76421c9d544b1885360c43.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

直觀的可以看出對於佔據 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 生態的閘道器標準，賦予了閘道器新的使命，使得流量閘道器 + 微服務閘道器合二為一成為可能。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/6294dd2673f84ff8a1bc9afdaa88f9fe.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

MSE 釋出的雲原生閘道器在能力不打折的情況下，將兩層閘道器變為一層，不僅可以節省 50% 的資源成本，還可以降低運維及使用成本。

## 雲原生閘道器的優勢

### 效能更強勁

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/1e923829d4424b8a9c7f610a7ddf1628.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/80c28de9d1b34124a6c1c205316a480f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

我們也檢視了 Nginx Ingress 的實現以及社群反饋，由於其大量使用 Lua 指令碼從而對效能帶來了非常大的影響，K8s Nginx Ingress 社群也有具體的 issue：
https://github.com/kubernetes/ingress-nginx/issues/5658

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/3f97f5ba428a41a2923c4d9e5af2772a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 功能更豐富

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/9d51fb9c80ba439b8a6240ab8b8b5b08.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 穩定更可靠

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/3b1cd516ed20463baad74a7ec19c7e4d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## 雲原生閘道器即將上線的重磅功能

### TLS 硬體加速

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/86d1ad244e25487b93a37584c5aa9548.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

### 內建 Waf

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

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/5283dc6b087d4fc5a958f39170f08146.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

###  Wasm 外掛市場

Wasm 作為目前非常火熱的技術之一，其最受追捧的原因在於其可以支援多語言編寫 Wasm 程式，且 Wasm 提供了一個很好的沙箱環境來控制程式的執行環境，Istiod 與 Envoy 社群也已經對 Wasm 外掛做了基礎的支援，雲原生閘道器希望在社群的基礎上推出自己的外掛市場，提升閘道器的可擴充套件性，方便使用者自定義閘道器外掛。我們也對現有的 wasm runtime 做了效能對比與測試，這些測試資料也會作為我們的開發依據，圖示如下：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/0cfd6fb6fc0d4fea9a2438047c2ed242.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center)

## 寫在最後

MSE - 雲原生閘道器，旨在為使用者提供更可靠的、成本更低、效率更高的，符合 K8s Ingress 標準的企業級閘道器產品，更多釋出詳情移步直播間觀看：
https://yqh.aliyun.com/live/detail/27794

MSE - 雲原生閘道器提供後付費和包年包月兩類付費模式，支援杭州、上海、北京、深圳 、張家口、香港、新加坡、美國（弗吉尼亞）、美國（矽谷）、德國（法蘭克福）10 個 region，並會逐步開放其他 region，雲原生閘道器購買連結請點選[此處](https://www.aliyun.com/product/aliware/mse?spm=5176.19720258.J_2937333540.8.652f2c4ag5onyh&scm=20140722.B_8470.P_5034.MO_406-ST_4277-ID_26497-CID_26497-V_1)。

也可釘釘搜尋群號 34754806 加入使用者群進行交流、答疑。

K8s Ingress Provider 為什麼選擇 MSE 雲原生閘道器？

相關文章