作者：張添翼(澄潭)

為了避免混淆，我們先對一些關鍵定義做一些釐清：

• 傳統閘道器：未作容器化改造，未啟用 K8s，通過流量閘道器與業務閘道器兩層閘道器來構建，流量閘道器提供全域性性的、與後端業務無關的策略配置，例如 Tengine 就是典型的流量閘道器；業務閘道器提供獨立業務域級別的、與後端業務緊耦合策略配置，隨著應用架構模式從單體演進到現在的分散式微服務，業務閘道器也有了新的叫法 - 微服務閘道器。

• K8s 閘道器：即雲原生閘道器，也被稱為下一代閘道器，Ingress 成為 K8s 生態的閘道器標準，促使流量閘道器和業務閘道器，合二為一。基於 Ingress 規範的實現主要分為基於 Nginx 和基於 Envoy 兩大陣營，基於 Nginx 的 Nginx Ingress Controller 是目前大多數 K8s 叢集的選擇，基於 Envoy 的實現作為後起之秀，大有趕超之勢。

• MSE 雲原生閘道器：是基於 Envoy，做了深度優化的雲上服務。

本文將從效能和成本、可靠性、安全性 3 方面，對兩大開源實現進行比對，希望對正在做 K8s 閘道器選型的企業有所借鑑。

效能和成本

MSE 雲原生閘道器的吞吐效能幾乎是 Nginx Ingress Controller 的一倍，尤其是傳輸小文字時效能優勢會更明顯，如下圖所示，閘道器 CPU 使用率達到 30% 時的吞吐對比：

閘道器規格：16 核 32 G * 4 節點

ECS 型號：ecs.c7.8xlarge

當 CPU 負載升高時，吞吐差距會更加明顯，下圖是 CPU 使用率達到 70% 時的情況：

高負載下 Nginx Ingress Controller  吞吐下降原因是出現了 pod 重啟，詳情見下一節“可靠性”中的分析。

隨著網路安全愈加受重視，現在網際網路上已經普遍使用 HTTPS 進行傳輸加密，在閘道器側，用於實現 HTTPS 的 TLS 非對稱加密演算法是佔用 CPU 資源的大頭。針對此場景，MSE 雲原生閘道器使用了 CPU SIMD 技術實現了 TLS 加解密演算法的硬體加速：

從上圖壓測資料可以看出使用 TLS 硬體加速後，相比普通 HTTPS 請求 TLS 握手時延降低一倍，極限 QPS 提升 80%以上。

基於以上資料，使用 MSE 雲原生閘道器，只需一半的資源，就能達到 Nginx Ingress Controller 的吞吐，在做過硬體加速優化的 HTTPS 場景下，吞吐還能進一步提升。

可靠性

前文提到高負載下，Nginx Ingress Controller 會出現 pod 重啟導致吞吐下降，導致 pod 重啟的原因主要有 2 點：

• 存活健康檢查（livenessProbe）在高負載時容易超時失敗，社群在 0.34 版本通過減少冗餘檢測進行了一定的優化，但問題仍然存在。

• 在開啟了 prometheus 採集監控指標的情況下，高負載時會出現 OOM，導致容器被 kill，詳細原因見相關 issue：https://github.com/kubernetes/ingress-nginx/pull/8397

這兩個問題，本質上皆是由於 Nginx Ingress Controller 的部署架構不合理導致。其控制面（Go 實現的 Controller）和資料面（Nginx）程序混跑在一個容器內，高負載下，資料面程序和控制面程序出現了 CPU 搶佔。其中控制面程序負責了健康檢查和監控指標採集，因為沒有足夠的 CPU 導致請求積壓引起 OOM 以及健康檢查超時。

這種情況是極危險的，會在高負載下引發閘道器的雪崩效應，對業務造成嚴重影響。MSE 雲原生閘道器使用了資料面和控制面隔離的架構，在架構上具備可靠性優勢：

從上圖可以看到，MSE 雲原生閘道器並不部署在使用者的 K8s 叢集中，而是純託管的模式，這種模式在可靠性上還有更多優勢：

• 不會與業務容器混跑在一個 ECS 節點上
• 閘道器的多個例項不會混跑在一個 ECS 節點上
• 提供閘道器可用性的 SLA 保障

如果使用 Nginx Ingress Controller 要實現高可靠部署，一般需要獨佔 ECS 節點，同時還需要部署多個 ECS 節點，來避免單點故障，這種情況下資源成本會直線上升。此外，Nginx Ingress Controller 因為部署在使用者叢集中，也無法提供閘道器可用性的 SLA 保障。

安全性

Nginx Ingress Controller 的不同版本都還存在著一些 CVE 漏洞隱患，具體影響版本見下表：

從  Nginx Ingress Controller 遷移到 MSE 雲原生閘道器後，將一次性修復所有 CVE 漏洞隱患；並且，MSE 雲原生閘道器提供了平滑升級方案，一旦出現新的安全漏洞，可以快速對閘道器版本進行升級，同時確保升級過程對業務影響最小化。

此外，MSE 雲原生閘道器內建了阿里雲 Web 應用防火牆（WAF），相比傳統 WAF 使用者請求鏈路更短、RT 更低，且相比Nginx Ingress Controller 可以做到細粒度路由級防護，使用成本是目前阿里雲 Web 應用防火牆架構的 2/3。

MSE 雲原生閘道器

阿里雲容器服務應用市場已經上架 MSE 雲原生閘道器，可用於替代預設安裝的閘道器元件 Nginx Ingress Controller。

MSE 雲原生閘道器在阿里集團內部作為閘道器中介軟體已經大規模使用，其強勁的效能和可靠的穩定性已被多年雙十一流量所驗證。

在 K8s 容器服務場景下，對比預設安裝的 Nginx Ingress Controller，主要有以下優勢：

• 更強勁的效能，更合理的架構，可以將閘道器資源成本降低至少 50%
• 更好的可靠性和 SLA 保障，純託管免運維，背靠阿里雲技術團隊提供支援
• 更優的安全性保障，一次性解決現存 CVE 安全漏洞隱患，且內建 WAF 防護功能

同時在路由策略、灰度治理、可觀測等方面提供了更豐富的功能，並且支援使用多種語言開發自定義的擴充套件外掛，詳細對比請參考：https://help.aliyun.com/document_detail/424833.html

平滑遷移方案

部署 MSE 雲原生閘道器並不直接影響原有閘道器流量，通過 DNS 權重配置可以實現業務流量的平滑遷移，對後端業務完全無感知，核心的流量遷移過程如下圖所示：

完整步驟如下：

• 步驟一：在容器服務的應用市場中找到 mse-ingress-controller，並安裝到目標 ACK 叢集

• 步驟二：在 K8s 中配置 MseIngressConfig （配置指引），自動建立指定規格的 MSE 雲原生閘道器

• 步驟三：從 Ingress 的 address 欄位中獲取 MSE 雲原生閘道器的 IP，本地繫結 host，將業務域名解析到該 IP，完成業務測試

• 步驟四：修改業務域名的 DNS 權重配置，新增雲原生閘道器 IP，並逐步調高權重，進行流量灰度

• 步驟五：完成灰度後，將業務域名原先的 IP 從 DNS 配置中移除，實現全部流量切到雲原生閘道器

點選此處，瞭解更多雲原生閘道器產品資訊~