01

K8s Ingress 簡介

Cloud Native

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

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

02

K8s Ingress 現(xiàn)狀

Cloud Native

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

03

K8s Ingress Provider 的發(fā)展趨勢

Cloud Native

Ingress Provider 的百花齊放，站在用戶角度各有利弊，好處是用戶的可選項很多，而壞處也恰恰是選擇太多，我們?nèi)绾稳ミx擇一個適合自身業(yè)務(wù)的 Ingress Provider 呢？不妨先看看權(quán)威 CNCF 的統(tǒng)計數(shù)據(jù)：

直觀的可以看出對于占據(jù) Ingress Provider 首位的 Nginx 是在預(yù)期之內(nèi)的，細(xì)看之下雖 Nginx Ingress 仍占據(jù)榜首，但其增長有點乏力，甚至有下降的態(tài)勢；反觀 Envoy 已經(jīng)從 2019 年的第三位攀升至 2020 的第二位，其使用率也從 2019 年的不足 20% 攀升至  2020 年的 37%，幾乎成倍增長。
所謂透過現(xiàn)象看本質(zhì)，為什么 Envoy 的增長這么快呢？總結(jié)起來有以下幾點：

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

   
   

2. Envoy 即可用作 Ingress Provider，也是 ServiceMesh 中 sidecar 的事實領(lǐng)導(dǎo)者，使用同一種技術(shù)同時解決南北向與東西向流量調(diào)度也是用戶選擇 Envoy 的一大原因。

   
   

3. Envoy 是達(dá)到生產(chǎn)級要求的，是經(jīng) Lyft 大規(guī)模驗證過的。

04

K8s Ingress Provider 的新選擇 - 云原生網(wǎng)關(guān)

Cloud Native

在虛擬化時期的微服務(wù)架構(gòu)下，業(yè)務(wù)通常采用流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)，流量網(wǎng)關(guān)負(fù)責(zé)南北向流量調(diào)度和安全防護(hù)，微服務(wù)網(wǎng)關(guān)負(fù)責(zé)東西向流量調(diào)度和服務(wù)治理，而在容器和 K8s 主導(dǎo)的云原生時代，Ingress 成為 K8s 生態(tài)的網(wǎng)關(guān)標(biāo)準(zhǔn)，賦予了網(wǎng)關(guān)新的使命，使得流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)合二為一成為可能。

MSE 發(fā)布的云原生網(wǎng)關(guān)在能力不打折的情況下，將兩層網(wǎng)關(guān)變?yōu)橐粚?，不僅可以節(jié)省 50% 的資源成本，還可以降低運維及使用成本。
05

云原生網(wǎng)關(guān)的優(yōu)勢

Cloud Native

1 性能更強勁

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

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

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

云原生網(wǎng)關(guān)作為流量網(wǎng)關(guān)與微服務(wù)網(wǎng)關(guān)的二合一，其功能上同時提供豐富的安全認(rèn)證與服務(wù)治理能力，同時在性能上也做了內(nèi)核調(diào)優(yōu)以及接下來要發(fā)布的硬件加速功能，結(jié)合阿里內(nèi)部兩年的大促經(jīng)驗在高可用建設(shè)上也進(jìn)一步做了擴(kuò)展3 穩(wěn)定更可靠

經(jīng)過歷年大促的驗證，阿里內(nèi)部積累了一套高可用保障方案，從研發(fā)時、運行時、變更時來控制風(fēng)險提升穩(wěn)定性，在每個階段各自有手段去驗證其高可用目標(biāo)06

云原生網(wǎng)關(guān)即將上線的重磅功能

Cloud Native

1 TLS 硬件加速

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

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

 Wasm 插件市場

Wasm 作為目前非?；馃岬募夹g(shù)之一，其最受追捧的原因在于其可以支持多語言編寫 Wasm 程序，且 Wasm 提供了一個很好的沙箱環(huán)境來控制程序的執(zhí)行環(huán)境，Istiod 與 Envoy 社區(qū)也已經(jīng)對 Wasm 插件做了基礎(chǔ)的支持，云原生網(wǎng)關(guān)希望在社區(qū)的基礎(chǔ)上推出自己的插件市場，提升網(wǎng)關(guān)的可擴(kuò)展性，方便用戶自定義網(wǎng)關(guān)插件。我們也對現(xiàn)有的 wasm runtime 做了性能對比與測試，這些測試數(shù)據(jù)也會作為我們的開發(fā)依據(jù)

MSE - 云原生網(wǎng)關(guān)提供后付費和包年包月兩類付費模式，支持杭州、上海、北京、深圳 、張家口、香港、新加坡、美國（弗吉尼亞）、美國（硅谷）、德國（法蘭克福）10 個 region，并會逐步開放其他 region，云原生網(wǎng)關(guān)購買鏈接請聯(lián)系站內(nèi)客服。