K8s 网关选型初判：Nginx 还是 Envoy？

作者：张添翼(澄潭)

为了避免混淆，我们先对一些关键定义做一些厘清：

• 传统网关：未作容器化改造，未启用 K8s，通过流量网关与业务网关两层网关来构建，流量网关提供全局性的、与后端业务无关的策略配置，例如 Tengine 就是典型的流量网关；业务网关提供独立业务域级别的、与后端业务紧耦合策略配置，随着应用架构模式从单体演进到现在的分布式微服务，业务网关也有了新的叫法 - 微服务网关。
• K8s 网关：即云原生网关，也被称为下一代网关，Ingress 成为 K8s 生态的网关标准，促使流量网关和业务网关，合二为一。基于 Ingress 规范的实现主要分为基于 Nginx 和基于 Envoy 两大阵营，基于 Nginx 的 Nginx Ingress Controller 是目前大多数 K8s 集群的选择，基于 Envoy 的实现作为后起之秀，大有赶超之势。
• MSE 云原生网关：是基于 Envoy，做了深度优化的云上服务。

本文将从性能和成本、可靠性、安全性 3 方面，对两大开源实现进行比对，希望对正在做 K8s 网关选型的企业有所借鉴。

性能和成本

Cloud Native

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 场景下，吞吐还能进一步提升。

可靠性

Cloud Native

前文提到高负载下，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 保障。

安全性

Cloud Native

Nginx Ingress Controller 的不同版本都还存在着一些 CVE 漏洞隐患，具体影响版本见下表：

CVE 漏洞列表	影响说明	开源 Nginx Ingress 受影响版本	ACK Nginx Ingress 受影响版本
CVE-2022-0778	依赖库 OpenSSL 漏洞，可用于实现 DoS 攻击	< 1.1.3	<  v1.1.2-aliyun.2
CVE-2022-23308	依赖库 libxml2 漏洞，可用于实现 DoS 攻击
CVE-2021-23017	Nginx 漏洞，通过伪造 DNS 响应，可用于实现 DoS 攻击，以及执行任意代码	< 0.47.0	< v0.44.0.3-8e83e7dc6-aliyun
CVE-2018-16843	Nginx 漏洞，使用 HTTP2 可能造成大量内存消耗，可用于实现 DoS 攻击	< 0.26.0	< v0.30.0.1-5f89cb606-aliyun
CVE-2019-9516
CVE-2018-16844	Nginx 漏洞，使用 HTTP2 可能造成大量 CPU 消耗，可用于实现 DoS 攻击
CVE-2019-9511
CVE-2019-9513

从  Nginx Ingress Controller 迁移到 MSE 云原生网关后，将一次性修复所有 CVE 漏洞隐患；并且，MSE 云原生网关提供了平滑升级方案，一旦出现新的安全漏洞，可以快速对网关版本进行升级，同时确保升级过程对业务影响最小化。

此外，MSE 云原生网关内置了阿里云 Web 应用防火墙（WAF），相比传统 WAF 用户请求链路更短、RT 更低，且相比Nginx Ingress Controller 可以做到细粒度路由级防护，使用成本是目前阿里云 Web 应用防火墙架构的 2/3。

MSE 云原生网关

Cloud Native

阿里云容器服务应用市场已经上架 MSE 云原生网关，可用于替代默认安装的网关组件 Nginx Ingress Controller。

MSE 云原生网关在阿里集团内部作为网关中间件已经大规模使用，其强劲的性能和可靠的稳定性已被多年双十一流量所验证。

在 K8s 容器服务场景下，对比默认安装的 Nginx Ingress Controller，主要有以下优势：

• 更强劲的性能，更合理的架构，可以将网关资源成本降低至少 50%
• 更好的可靠性和 SLA 保障，纯托管免运维，背靠阿里云技术团队提供支持
• 更优的安全性保障，一次性解决现存 CVE 安全漏洞隐患，且内置 WAF 防护功能

同时在路由策略、灰度治理、可观测等方面提供了更丰富的功能，并且支持使用多种语言开发自定义的扩展插件，详细对比请参考：

https://help.aliyun.com/document_detail/424833.html

平滑迁移方案

Cloud Native

部署 MSE 云原生网关并不直接影响原有网关流量，通过 DNS 权重配置可以实现业务流量的平滑迁移，对后端业务完全无感知，核心的流量迁移过程如下图所示：

完整步骤如下：

• 步骤一：在容器服务的应用市场中找到 mse-ingress-controller，并安装到目标 ACK 集群
• 步骤二：在 K8s 中配置 MseIngressConfig （配置指引），自动创建指定规格的 MSE 云原生网关
• 步骤三：从 Ingress 的 address 字段中获取 MSE 云原生网关的 IP，本地绑定 host，将业务域名解析到该 IP，完成业务测试
• 步骤四：修改业务域名的 DNS 权重配置，添加云原生网关 IP，并逐步调高权重，进行流量灰度
• 步骤五：完成灰度后，将业务域名原先的 IP 从 DNS 配置中移除，实现全部流量切到云原生网关

点击阅读原文，了解更多云原生网关产品信息~