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

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

传统网关：未作容器化改造，未启用 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 保障。