K8s 閘道器選型初判:Nginx 還是 Envoy?

語言: CN / TW / HK

作者:張添翼(澄潭)

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

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

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

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

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

效能和成本

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

1.png

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

ECS 型號:ecs.c7.8xlarge

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

2.png

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

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

3.png

從上圖壓測資料可以看出使用 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 雲原生閘道器使用了資料面和控制面隔離的架構,在架構上具備可靠性優勢:

4.png

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

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

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

安全性

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

5.png

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

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

6.png

MSE 雲原生閘道器

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

7.png

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

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

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

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

平滑遷移方案

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

8.png

完整步驟如下:

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

  • 步驟二:在 K8s 中配置 MseIngressConfig (配置指引),自動建立指定規格的 MSE 雲原生閘道器

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

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

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

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