NGINX Ingress Controller 和 Red Hat OpenShift Router 性能测试

Red Hat OpenShift 容器平台 (OCP) 是最受欢迎的托管 Kubernetes 平台之一，与其竞争对手一样，OCP 包含默认流量管理工具，以帮助用户快速上手。 基于HAProxy的OCP 路由器是 OCP 集群的默认入口点。 它可以平衡 HTTP 和 WebSocket 流量的负载，支持路由器与应用实例之间的 TLS 终止和 TLS，并且可以以直通模式平衡 TLS 连接的负载。

客户经常问我们：“既然路由器是免费提供的，为什么我应该在 OpenShift 中使用 NGINX Ingress Controller？” 在为什么需要 OpenShift 上的企业级入口控制器中，GigaOm 的客座博主 Max Mortillaro 分享了一些您可能想要使用NGINX 入口控制器的定性原因：高级流量管理、易于使用、JWT 验证和 WAF 集成。 但从定量的角度回答这个问题也很重要，这就是为什么我们在 OCP 环境中对路由器和基于 NGINX Plus 的NGINX 入口控制器（ nginxinc/kubernetes-ingress ）进行性能测试，在动态部署中，我们在测试期间增加和减少上游（后端）服务器的数量。

当我们进行性能测试时，我们会考虑两个因素来评估工具的性能：

• 因素 1： 动态部署的延迟结果

  我们发现，衡量动态部署中最终用户体验的最有效指标是延迟百分位分布。 系统增加的延迟越多，用户体验受到的影响就越大。 我们还发现，为了真实地了解用户体验，需要包括分布中上百分位数的延迟；有关详细说明，请参阅 性能结果 部分 NGINX 和 HAProxy： 在云中测试用户体验 在我们的博客上。

• 因素 2： 超时和错误

  当被测系统在动态部署中导致延迟时，通常是因为系统难以处理动态重新加载、出现超时或错误。

性能测试结果

让我们直接进入有趣的部分并回顾一下结果。 以下是有关测试拓扑和方法的详细信息。

如上所述，我们在评估性能时考虑两个因素：延迟和超时/错误。

因素 1： 延迟百分位分布

如下图所示，NGINX Ingress Controller 在整个测试过程中增加的延迟可以忽略不计，在 99.999 百分位达到最大值小于 700 毫秒。 相比之下，OCP 路由器在相当低的百分位数时增加了延迟，并且延迟呈指数增加，直到在 99.99 百分位数时稳定在略高于 25,000 毫秒（25 秒）的水平。 这表明，当负载过大且集群环境频繁发生变化时，路由器可能会导致糟糕的用户体验。

因素 2： 超时和错误

上面观察到的延迟可归因于超时和错误：OCP 路由器产生 260 次连接超时和 85 次读取套接字错误，而 NGINX Ingress Controller 没有产生任何错误。 正如我们在其他性能测试中看到的那样（请参阅在动态 Kubernetes 云环境中对 NGINX 入口控制器进行性能测试），路由器的超时和错误是由 HAproxy 处理动态重新加载的方式引起的。 基于 NGINX Plus 的NGINX Ingress Controller 不会导致超时或错误，因为它使用NGINX Plus API在端点发生变化时动态更新 NGINX 配置。

测试设置和方法

测试拓扑

我们在 NGINX Ingress Controller 和 OpenShift Router 上运行了与被测系统 (SUT) 相同的测试。 SUT 终止来自客户端的 TLS 1.3 连接，并通过单独的连接将客户端请求转发到后端部署。

客户端托管在运行 CentOS 7 的单独机器上，与 OpenShift 集群位于同一 LAN 上。

SUT 和后端部署在托管于 VMware vSphere 6.7.0.45100 的 OCP 集群中运行。

对于 TLS 加密，我们使用了具有2048 位密钥大小和完美前向保密的 RSA。

来自后端应用的每个响应都包含大约 1 KB的基本服务器元数据，以及200好的HTTP 状态代码。

测试方法

客户端部署

我们使用wrk2 （版本 4.0.0）在客户端机器上运行以下脚本，以每秒 1000 个请求（RPS，用-R选项设置）的恒定吞吐量运行测试 60 秒（用-d选项设置）：

./wrk -t 2 -c 50 -d 60s -R 1000 -L https:// ingress-url :443/

使用的 SUT 软件

• OpenShift Platform 版本 4.8，默认包含基于 HAProxy 的路由器
• NGINX Ingress 控制器版本 1.11.0 （NGINX Plus R22）

后端部署

我们对后端应用的动态部署进行了测试运行，使用以下脚本定期增加和减少后端副本的数量。 这模拟了动态 OpenShift 环境并测量 NGINX Ingress Controller 或 OCP Router 适应端点变化的效率。

while [ 1 -eq 1 ]
do
oc scale 部署 nginx-backend --replicas=4 
sleep 10 
oc scale 部署 nginx-backend --replicas=2
sleep 10
done

结论

大多数采用微服务方法的公司正在通过其 CI/CD 管道以比以往更高的频率推动新的发展。 因此，至关重要的是利用可随着这些新方法在功能和性能上不断发展的数据平面，而不会破坏最终用户的体验。 提供最佳的最终用户体验涉及在任何情况下为所有客户端连接持续提供低延迟。

根据性能结果，NGINX Ingress Controller 在需要大量迭代和改进开发的容器化环境中提供了最佳的最终用户体验。

首先，下载NGINX Ingress Controller 的免费试用版，并了解如何使用NGINX Ingress Operator进行部署。