為了避免混淆，我們先對一些關鍵定義做一些厘清：
- 傳統(tǒng)網(wǎng)關：未作容器化改造，未啟用 K8s，通過流量網(wǎng)關與業(yè)務網(wǎng)關兩層網(wǎng)關來構建，流量網(wǎng)關提供全局性的、與后端業(yè)務無關的策略配置，例如 Tengine 就是典型的流量網(wǎng)關；業(yè)務網(wǎng)關提供獨立業(yè)務域級別的、與后端業(yè)務緊耦合策略配置，隨著應用架構模式從單體演進到現(xiàn)在的分布式微服務，業(yè)務網(wǎng)關也有了新的叫法 – 微服務網(wǎng)關。
- K8s 網(wǎng)關：即云原生網(wǎng)關，也被稱為下一代網(wǎng)關，Ingress 成為 K8s 生態(tài)的網(wǎng)關標準，促使流量網(wǎng)關和業(yè)務網(wǎng)關，合二為一?；?Ingress 規(guī)范的實現(xiàn)主要分為基于 Nginx 和基于 Envoy 兩大陣營，基于 Nginx 的 Nginx Ingress Controller 是目前大多數(shù) K8s 集群的選擇，基于 Envoy 的實現(xiàn)作為后起之秀，大有趕超之勢。
- MSE 云原生網(wǎng)關：是基于 Envoy，做了深度優(yōu)化的云上服務。
本文將從性能和成本、可靠性、安全性 3 方面，對兩大開源實現(xiàn)進行比對，希望對正在做 K8s 網(wǎng)關選型的企業(yè)有所借鑒。
性能和成本
MSE 云原生網(wǎng)關的吞吐性能幾乎是 Nginx Ingress Controller 的一倍，尤其是傳輸小文本時性能優(yōu)勢會更明顯，如下圖所示，網(wǎng)關 CPU 使用率達到 30% 時的吞吐對比：
網(wǎng)關規(guī)格：16 核 32 G * 4 節(jié)點
ECS 型號：ecs.c7.8xlarge
當 CPU 負載升高時，吞吐差距會更加明顯，下圖是 CPU 使用率達到 70% 時的情況：
高負載下 Nginx Ingress Controller 吞吐下降原因是出現(xiàn)了 pod 重啟，詳情見下一節(jié)“可靠性”中的分析。
隨著網(wǎng)絡安全愈加受重視，現(xiàn)在互聯(lián)網(wǎng)上已經(jīng)普遍使用 HTTPS 進行傳輸加密，在網(wǎng)關側(cè)，用于實現(xiàn) HTTPS 的 TLS 非對稱加密算法是占用 CPU 資源的大頭。針對此場景，MSE 云原生網(wǎng)關使用了 CPU SIMD 技術實現(xiàn)了 TLS 加解密算法的硬件加速：
從上圖壓測數(shù)據(jù)可以看出使用 TLS 硬件加速后，相比普通 HTTPS 請求 TLS 握手時延降低一倍，極限 QPS 提升 80%以上。
基于以上數(shù)據(jù)，使用 MSE 云原生網(wǎng)關，只需一半的資源，就能達到 Nginx Ingress Controller 的吞吐，在做過硬件加速優(yōu)化的 HTTPS 場景下，吞吐還能進一步提升。
可靠性
前文提到高負載下，Nginx Ingress Controller 會出現(xiàn) pod 重啟導致吞吐下降，導致 pod 重啟的原因主要有 2 點：
- 存活健康檢查（livenessProbe）在高負載時容易超時失敗，社區(qū)在 0.34 版本通過減少冗余檢測進行了一定的優(yōu)化，但問題仍然存在。
- 在開啟了 prometheus 采集監(jiān)控指標的情況下，高負載時會出現(xiàn) OOM，導致容器被 kill，詳細原因見相關 issue：https://github.com/kubernetes/ingress-nginx/pull/8397
這兩個問題，本質(zhì)上皆是由于 Nginx Ingress Controller 的部署架構不合理導致。其控制面（Go 實現(xiàn)的 Controller）和數(shù)據(jù)面（Nginx）進程混跑在一個容器內(nèi)，高負載下，數(shù)據(jù)面進程和控制面進程出現(xiàn)了 CPU 搶占。其中控制面進程負責了健康檢查和監(jiān)控指標采集，因為沒有足夠的 CPU 導致請求積壓引起 OOM 以及健康檢查超時。
這種情況是極危險的，會在高負載下引發(fā)網(wǎng)關的雪崩效應，對業(yè)務造成嚴重影響。MSE 云原生網(wǎng)關使用了數(shù)據(jù)面和控制面隔離的架構，在架構上具備可靠性優(yōu)勢：
從上圖可以看到，MSE 云原生網(wǎng)關并不部署在用戶的 K8s 集群中，而是純托管的模式，這種模式在可靠性上還有更多優(yōu)勢：
- 不會與業(yè)務容器混跑在一個 ECS 節(jié)點上
- 網(wǎng)關的多個實例不會混跑在一個 ECS 節(jié)點上
- 提供網(wǎng)關可用性的 SLA 保障
如果使用 Nginx Ingress Controller 要實現(xiàn)高可靠部署，一般需要獨占 ECS 節(jié)點，同時還需要部署多個 ECS 節(jié)點，來避免單點故障，這種情況下資源成本會直線上升。此外，Nginx Ingress Controller 因為部署在用戶集群中，也無法提供網(wǎng)關可用性的 SLA 保障。
安全性
Nginx Ingress Controller 的不同版本都還存在著一些 CVE 漏洞隱患，具體影響版本見下表：
從 Nginx Ingress Controller 遷移到 MSE 云原生網(wǎng)關后，將一次性修復所有 CVE 漏洞隱患；并且，MSE 云原生網(wǎng)關提供了平滑升級方案，一旦出現(xiàn)新的安全漏洞，可以快速對網(wǎng)關版本進行升級，同時確保升級過程對業(yè)務影響最小化。
此外，MSE 云原生網(wǎng)關內(nèi)置了阿里云 Web 應用防火墻（WAF），相比傳統(tǒng) WAF 用戶請求鏈路更短、RT 更低，且相比Nginx Ingress Controller 可以做到細粒度路由級防護，使用成本是目前阿里云 Web 應用防火墻架構的 2/3。
MSE 云原生網(wǎng)關
阿里云容器服務應用市場已經(jīng)上架 MSE 云原生網(wǎng)關，可用于替代默認安裝的網(wǎng)關組件 Nginx Ingress Controller。
MSE 云原生網(wǎng)關在阿里集團內(nèi)部作為網(wǎng)關中間件已經(jīng)大規(guī)模使用，其強勁的性能和可靠的穩(wěn)定性已被多年雙十一流量所驗證。
在 K8s 容器服務場景下，對比默認安裝的 Nginx Ingress Controller，主要有以下優(yōu)勢：
- 更強勁的性能，更合理的架構，可以將網(wǎng)關資源成本降低至少 50%
- 更好的可靠性和 SLA 保障，純托管免運維，背靠阿里云技術團隊提供支持
- 更優(yōu)的安全性保障，一次性解決現(xiàn)存 CVE 安全漏洞隱患，且內(nèi)置 WAF 防護功能
同時在路由策略、灰度治理、可觀測等方面提供了更豐富的功能，并且支持使用多種語言開發(fā)自定義的擴展插件，詳細對比請參考：https://help.aliyun.com/document_detail/424833.html
平滑遷移方案
部署 MSE 云原生網(wǎng)關并不直接影響原有網(wǎng)關流量，通過 DNS 權重配置可以實現(xiàn)業(yè)務流量的平滑遷移，對后端業(yè)務完全無感知，核心的流量遷移過程如下圖所示：
完整步驟如下：
- 步驟一：在容器服務的應用市場中找到 mse-ingress-controller，并安裝到目標 ACK 集群
- 步驟二：在 K8s 中配置 MseIngressConfig （配置指引），自動創(chuàng)建指定規(guī)格的 MSE 云原生網(wǎng)關
- 步驟三：從 Ingress 的 address 字段中獲取 MSE 云原生網(wǎng)關的 IP，本地綁定 host，將業(yè)務域名解析到該 IP，完成業(yè)務測試
- 步驟四：修改業(yè)務域名的 DNS 權重配置，添加云原生網(wǎng)關 IP，并逐步調(diào)高權重，進行流量灰度
- 步驟五：完成灰度后，將業(yè)務域名原先的 IP 從 DNS 配置中移除，實現(xiàn)全部流量切到云原生網(wǎng)關
作者：張?zhí)硪?澄潭)
原文鏈接：http://click.aliyun.com/m/1000345146/
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。
